You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2001/01/11 20:22:44 UTC
RFC: Logic TagLib
Dear Cocooners,
I develop XSP TagLibs, as part of my work on the CRUDLET project.
<http://www.crudlet.org>
We have developed a draft proposal of a TagLib for handling "content logic"
for webapps; to allow contextual content selection logic to be encoded in
an XSP page without the user having to write Java Code inside <xsp:logic/>
tags.
This is something that was critical for our project to allow us to develop
in a more scaleable way to the techniques we are using now.
The Logic TagLib was designed to be generic it has no dependencies on the
CRUDLET project, it was always intended to be contributed to Cocoon.
We invite all interested parties to read and comment on the proposal.
<http://www.crudlet.org/logicTaglib.html>
I understand that some people may find this controversial .... I am not too
worried, we know it is something we need ;) but I am interested in your
opinions and I am totally prepared to alter the specification, or to not
incorporate it into Cocoon or whatever, depending on the response.
As a taster, here are two examples from the proposal:
A simple test for equality between the value that arrived in the request
parameter called "blag" and an empty String. If the parameter was empty,
the TextNode "The request param is empty" is output to the parent element
of the <logic:if/> tag; otherwise there is no output.
<logic:if>
<logic:test op="eq">
<logic:arg><request:get-parameter name="blag"/></logic:arg>
<logic:arg/>
</logic:test>
<logic:then>The request param is empty</logic:then>
</logic:if>
This is a typical use of the <logic:choose/> tag whereby multiple
<logic:when/> clauses are evaluated until one of them returns something. If
none of them returned anything, the contents of <logic:otherwise/> is
output. There should be one or more <logic:when/> clauses and only one
<logic:otherwise/>. The equivalent forms of nesting available to the
<logic:if/> tag will also work with the <logic:choose/> tag.
<logic:choose>
<logic:when>
<logic:test op="eq">
<logic:arg><request:get-parameter name="type"/></logic:arg>
<logic:arg>fish</logic:arg>
</logic:test>
<logic:then>This is a Fish</logic:then>
</logic:when>
<logic:when>
<logic:test op="eq">
<logic:arg><request:get-parameter name="type"/></logic:arg>
<logic:arg>dogcow</logic:arg>
</logic:test>
<logic:then>This is a Dogcow</logic:then>
</logic:when>
<logic:otherwise>It was none of the above</logic:otherwise>
</logic:choose>
This will get implemented over the coming weeks.
Let me know what you think, (but please read the whole thing first ;)
Thanks
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: RFC: Logic TagLib
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 09:47 -0500 12/01/01, Andy Lewis wrote:
>I have less than no votoing rights, being a lurker here, but I
>completely agree with the seperation of concerns issue here. I actually
>am hesitiant about both XSP and JSP as a whole for exactly that reason.
>While they are really cool, I don't like risking my business logic - or
>really any significant logic ending up in the middle of my display code.
I understand.
What we have designed it for is not Business Logic, our Beans handle that,
we will use it for display logic.
Thanks for your response
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: RFC: Logic TagLib
Posted by Andy Lewis <an...@veritas.com>.
I have less than no votoing rights, being a lurker here, but I
completely agree with the seperation of concerns issue here. I actually
am hesitiant about both XSP and JSP as a whole for exactly that reason.
While they are really cool, I don't like risking my business logic - or
really any significant logic ending up in the middle of my display code.
Stefano Mazzocchi wrote:
> Jeremy Quinn wrote:
>
>> Dear Cocooners,
>>
>> I develop XSP TagLibs, as part of my work on the CRUDLET project.
>>
>> <http://www.crudlet.org>
>>
>> We have developed a draft proposal of a TagLib for handling "content
>> logic" for webapps; to allow contextual content selection logic to be
>> encoded in an XSP page without the user having to write Java Code
>> inside <xsp:logic/> tags.
>>
>> This is something that was critical for our project to allow us to
>> develop in a more scaleable way to the techniques we are using now.
>>
>
> I'll be honest: I don't like XMLized scripting languages as a general
> rule.
>
> It blurs the separation of concerns: who is going to use this syntax? a
> programmer? a document writer?
>
> Having a procedural programming language included into your page as
> another namespace appears more elegant than having a scriplet or
> something like that, but it's nothing different conceptually.
>
> Cocoon should aim at keep separation well defined and avoid unnecessary
> blurring.
>
> Let's keep the example above: it is the programmer concern to handle the
> error case where the request parameter is empty, *NOT* the
> document/template writer's.
>
> Do we want to create a scripting language using XML as a syntax? why? I
> see this as FS big time!
>
> The above should be written as
>
> <mylogic:do-something>
> <request:get-parameter name="blah"/>
> </mylogic:do-something>
>
> which should take into account all the errors. What about the error
> string? Right, it should be the writer's concern so we place it here
>
> <mylogic:do-something>
> <mylogic:message name="empty-param" xml:lang="en">
> The request param is empty.
> </mylogic:message>
> <mylogic:blah>
> <request:get-parameter name="blah"/>
> </mylogic:blah>
> </mylogic:do-something>
>
> and the contract with the document writer is simply the schema that
> "mylogic" namespace has.
>
> So, general anti-pattern: when you see <if>, <else>, <for> or even worse
> <goto> beware: you are turning a declarative syntax into a procedural
> semantic. And yes, even XSLT is somewhat too procedural in many parts.
>
> Disclaimer: this is my personal opinion only and I have no voting right
> at this moment so you decide what to do.
>
> My feeling is that people will start small and end up asking for an XML
> rewrite of their favorite programming language, which is pretty scary,
> don't you think?
>
Re: RFC: Logic TagLib
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
Dear Stefano and Cocoon Dev,
Sorry it has taken me so long to get back to you.
I needed some time to think about it, consult my colleagues etc.
Plus we have been in site drop overdrive hell for the last couple of days ;)
At 22:20 +0100 12/01/01, Stefano Mazzocchi wrote:
>[got back to the list since I think this is general enough to interest
>anyone and doesn't show anything that should remain private]
>
>Jeremy Quinn wrote:
>>
>> At 12:29 +0100 12/01/01, Stefano Mazzocchi wrote:
>> >It blurs the separation of concerns: who is going to use this syntax? a
>> >programmer? a document writer?
>>
>> It is designed as a TagLib for content writers.
>> Extreme, I agree, but the feedback I am getting from our writers is that
>> they understand it.
>
>Which is interesting.
>
>I've read your example carefully and I admit that once you got the
>semantic it's very straight forward.... but my concerns still remain as
>a general principle.
Yes, I understand
>> >Having a procedural programming language included into your page as
>> >another namespace appears more elegant than having a scriplet or
>> >something like that, but it's nothing different conceptually.
Yes, when I developed the FP TagLib, I got into the mindset of it being
like a language ....
>> >Cocoon should aim at keep separation well defined and avoid unnecessary
>> >blurring.
>>
>> I agree, I do not propose this lightly ;)
>
>Oh, I know that, but I believe that my role is to judge concern overlaps
>whenever I see one.
Which makes your continued contribution very welcome.
>> We unfortunately are dealing with a situation that does not fit so easily
>> within the nice and clean SoC diagram that is the ideal pattern for Cocoon.
>
>Sorry, but this is somewhat incorrect. All possible situations can be
>designed with a SoC diagram. The question is whether or not Cocoon's is
>valid for all situations.
[snip]
>Are you *positive* that this logic taglib isn't a short-term semi-hack?
>I say *semi-hack* beacause it's following the well-behaving XSP
>guidelines of avoiding mixing code with content.... but remember, the
>SoC diagram separates "logic" and "content"... and a Logic taglib is
>clearly against this notion.
You are being very polite about this :)
I guess few development processes are ever ideal!
Closer to the truth is that when the Crudlet code base architecture was
first developed, no one understood the issues of display logic. When I was
invited to join the project, the architecture had just about finalised and
the lack of a display logic layer was pointed out but not acted upon. The
project was too complex for anyone to understand enough of it to declare
unequivocally what was required. The project was developed+debugged in a
kind of boot-strap fashion, a pragmatic choice. Having completed the first
project using the architecture, we now understand what is good and what is
bad about it.
So, as you say, the Logic Taglib could well be a short term hack.
The critical issue for me was that because Crudlet is a generic framework,
requiring people to develop their own Beans within the system for their own
functionality, we still needed a generic solution for handling display
logic.
I could go through our site, picking out all of the logic tests in the XSL
and encode them as logic placeholders in our content, but they would be
totally dependant on our particular Beans. ie. "is this offer cloaked?" is
unique to our application. Exchange Beans that handle this are not part of
the OpenSource Crudlet package.
While developing the concept of a logic taglib over the last couple of
weeks, I thought, Hmm, maybe this could be useful for other Cocoon users
developing webapps. I realised that it was possible to make the logic stuff
completely generic, having nothing to do with the Crudlet taglib. But I
also realised the conceptual problems it brings ....
I think we (Crudlet.org) have several options:
1. Go ahead and implement what I have proposed, contribute it to Cocoon if
the vote goes that way.
2. As above, but remove <logic:if> as you pointed out, it is redundant.
3. Re-integrate the logic into the Crudlet TagLib, to allow the tags to be
less verbose, and less obviously "structured logic", because it will have
more intimate knowledge of Crudlet.
4. Redesign the Crudlet architecture to incorporate a display layer (no one
here appears confidant this is realistic, yet ...)
5. Try the other approach I came up with at the time I thought of a TagLib
as a solution .... use a second XSL pass to handle content selection,
having defined a simpler document DTD with which to encode selection
options.
I suspect 2 or 3 are the most likely short-term outcomes if we choose to
implement a TagLib, though after managing to discuss this with my
colleagues we feel the XSL approach is far more likely to meet SoC criteria.
We know that the Crudlet engine needs adjustments to the design, we know
that the way people will use this engine from Cocoon 2 will be very
different from Cocoon 1. The project needs to be moving forward all the
time, while remaining easily usable as we have many more projects to
develop with it.
>> Business Logic is embedded in the Beans we write to handle our application.
>> This is handled by the crudlet:taglib, fine.
>
>Yes, the crudlet taglib seems well designed for what I have seen. (why
>such a name, BTW?)
Crudlet stands for:
Create, Retrieve, Update, Delete, Lifecycle, Exists, Template
the "modes" of operation
see <http://www.crudlet.org>
[snip - lots of important stuff]
>Now, to have "complete" separation, "logic placeholders" must be
>semantically identified as "content" or "logic placeholders" must
>semantically identified as "logic".
>
>Since, normally, the "skeleton" of the information engineering is done
>by content writers, the second paradigm is normally considered more
>expensive for web programming.
Agreed
>For the "logic:" taglib, Jeremy is advocating that "<logic:if>" (which
>is his "logic placeholder") is percieved as "content" by content
>writers, thus it doesn't break separation.
>
>While I don't necessarely disagree with this assumption (if/then is not
>that hard to understand), it must be explicitly said that "procedural
>behavior" is somewhat alien to all categories of people but programmers.
I think you have helped us realise the conceptual mistake we were making in
choosing a TagLib to solve this problem. We are very grateful!
I am now starting to think about a way of marking up content with
information a generic StyleSheet can use to make our content selections for
us. (This is the part of my job I really enjoy :)
>Anyway, in all cases, this is just a taglib, it doesn't pollute the
>Cocoon model in any way. One thing: write a document to explain why this
>taglib can be abused and pages become more expensive to maintain in the
>long run if carefull design is not applied.
>
>Hope this helps and sorry for the length :)
This really helps.
We are again in your debt Stefano, thank you.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: RFC: Logic TagLib
Posted by Stefano Mazzocchi <st...@apache.org>.
[got back to the list since I think this is general enough to interest
anyone and doesn't show anything that should remain private]
Jeremy Quinn wrote:
>
> At 12:29 +0100 12/01/01, Stefano Mazzocchi wrote:
>
> Dear Stefano,
>
> Thank you for your reply.
>
> How are you? Well I hope!
Oh, yes. I'm fine, thank you.
> >Jeremy Quinn wrote:
> >>
> >> Dear Cocooners,
> >>
> >> I develop XSP TagLibs, as part of my work on the CRUDLET project.
>
> [snip]
>
> >
> >I'll be honest: I don't like XMLized scripting languages as a general
> >rule.
> >
> >It blurs the separation of concerns: who is going to use this syntax? a
> >programmer? a document writer?
>
> It is designed as a TagLib for content writers.
> Extreme, I agree, but the feedback I am getting from our writers is that
> they understand it.
Which is interesting.
I've read your example carefully and I admit that once you got the
semantic it's very straight forward.... but my concerns still remain as
a general principle.
> >Having a procedural programming language included into your page as
> >another namespace appears more elegant than having a scriplet or
> >something like that, but it's nothing different conceptually.
> >
> >Cocoon should aim at keep separation well defined and avoid unnecessary
> >blurring.
>
> I agree, I do not propose this lightly ;)
Oh, I know that, but I believe that my role is to judge concern overlaps
whenever I see one. If the list decides to allow some overalp and create
another concern area, it's ok with me, as long as they seriously thought
about the long term consequences of these actions.
> We unfortunately are dealing with a situation that does not fit so easily
> within the nice and clean SoC diagram that is the ideal pattern for Cocoon.
Sorry, but this is somewhat incorrect. All possible situations can be
designed with a SoC diagram. The question is whether or not Cocoon's is
valid for all situations.
I don't have enough experience myself for real-life situations to know
if this is true or not... but *everytime* I was called to revise
somebody else's SoC diagram, I found out that Cocoon's holds true. The
problems were lack of semantic understanding of the concerns, or bad
technology implemented on top of Cocoon.
Of course, I'm biased, so take this with a grain of salt, but I strongly
believe that the above is an excuse rather than a true motivation. Just
like entering code directly into an XSP/JSP page or deteriorating the
OOP paradigm during code production.
I'm not saying this is your case, mind you. But many times a solution is
simply measured with the wrong metric, normally with a
small-term-oriented one because of production pressure. And I fully
understand that. But expense curves clearly show that the time invested
in long-term design is time saved in later escalation.
Are you *positive* that this logic taglib isn't a short-term semi-hack?
I say *semi-hack* beacause it's following the well-behaving XSP
guidelines of avoiding mixing code with content.... but remember, the
SoC diagram separates "logic" and "content"... and a Logic taglib is
clearly against this notion.
> Business Logic is embedded in the Beans we write to handle our application.
> This is handled by the crudlet:taglib, fine.
Yes, the crudlet taglib seems well designed for what I have seen. (why
such a name, BTW?)
> However, we are writing complex webapps, they have "Display Logic".
Ok, let's elaborate on this notion then: what you need is a way to
display your data. You need a view!
You have the "model" which is the crudlet beans, then you have to
display something and you need a view for that.
Views can be as easy as
if (param = something)
print this
else
print that
but this easily grows into painfully complex logic. It's rather
optimistic to believe that views are always as simple as a few choices
over param equality, even if they appear to solve all your problems so
far.
> We cannot encode the Display Logic inside a TagLib in the simple way you
> have written below:
>
> 1. there is far to much of it (too many different questions to ask)
Granted, but many instances of an general class are funtionally
equivalent to many different single-instanced implementations of the
same interface. Translated in this context: isn't there a more
declarative way to express a view around a model without the use of
procedural "if/then/else/switch/case" conditionals?
It may not exist. I honestly don't know, but I think it's worth trying.
> 2. the negotiation of the logic is about which bit of content to show
> according to the current conditions. The actual content that is being
> negotiated needs to be accessible to content writers, not embedded inside
> another TagLib.
Oh, totally. This is why I passed parameters including the return
content.
Allow me to make a simple abstract analisys over logic/content
separation.
There are two possibilities to fully separate content and logic
1) place logic placeholders into content
or
2) place conten placeholders into logic
Now, to have "complete" separation, "logic placeholders" must be
semantically identified as "content" or "logic placeholders" must
semantically identified as "logic".
Since, normally, the "skeleton" of the information engineering is done
by content writers, the second paradigm is normally considered more
expensive for web programming.
This is why XSP follow the first approach (along with other technologies
like Velocity).
For the "logic:" taglib, Jeremy is advocating that "<logic:if>" (which
is his "logic placeholder") is percieved as "content" by content
writers, thus it doesn't break separation.
While I don't necessarely disagree with this assumption (if/then is not
that hard to understand), it must be explicitly said that "procedural
behavior" is somewhat alien to all categories of people but programmers.
Think about it: when you go to the toilet, do you carefully plan the
if/then/else pattern of actions taking care of every possible thing that
might happen to you during the path, or you simply have a default set of
declarative behaviors that are called when a particular event happens?
Now, remember how hard it was when you did your first programming to
"proceduralize" something that was "not" procedural in all of your life?
Those of you who personally experienced the "goto death" after moving
from, say, BASIC to more structured procedural languages such as Pascal
or C, know the feeling of loosing their mental processes. If this
happens in your teens, it's ok, no big deal, you form a new mindset, but
what if this happens in your thirdies?
This is what happens to writers if you force them to "proceduralize"
their behavior: they feel lost.
Now, can a conditional construct be removed from a declarative language?
I don't have a proof for this, but I believe that this is *not* true if
you aim to turing completeness.
But I have the feeling (again, no proof) that this might hold true if
you sacrificy some completeness and you move this over a full-blown
procedural programming language.
In this case, this means to move the conditional semantics into the
taglib, provide a declarative semantic for the taglib, yet keep it
sufficiently general to avoid the need to create many implementations.
Let's keep going: it can be proven that the if/then/else semantic is
totally equivalent to the switch/case/default one. The first construct
is strictly procedural, the second construct is a little more
declarative, yet they both provide the exact same logical functionality.
So, first result: having both is redundant. This isn't necessarely bad
(see XSLT which has both), but I will go on assuming that the
conditional construct is choose/when/otherwise, which is totally
equivalent with the C-like switch/case/default.
> >Let's keep the example above: it is the programmer concern to handle the
> >error case where the request parameter is empty, *NOT* the
> >document/template writer's.
>
> Yea, sorry, it was a trivial example.
>
> I have included my first attempt at writing one of our pages with the new
> Logic Tags, for you to see the scale of the problem. (Sorry)
Let's take a snapshot of your more juicy page (content edited for
privacy)
<block name="instructions">
<logic:choose>
<logic:when>
<logic:test op="eq">
<logic:arg>
<crudlet:value-of property="SenderUsername" bean="publicOffer"/>
</logic:arg>
<logic:arg>
<crudlet:value-of property="Username" bean="UserBean"/>
</logic:arg>
</logic:test>
<logic:then>
<p>[a bunch of text]</b>
</logic:then>
</logic:when>
<logic:otherwise>
<logic:choose>
<logic:when>
<logic:test op="eq">
<logic:arg>
<crudlet:value-of property="IsCloaked" bean="publicOffer"/>
</logic:arg>
<logic:arg>
Remain Anonymous
</logic:arg>
</logic:test>
<logic:then>
[some other text]
</logic:then>
</logic:when>
</logic:choose>
<p>some additional information</p>
</logic:otherwise>
</logic:choose>
</block>
Let's do a semantic analysis on this and let's try to come up with a
natural-language explaination of what this markup fragment means:
When the user is the one who sent the public offer, print specific
instructions, otherwise if the offer creator wants to remain anonymous,
print anonymous instructions; in all this second case indicate some
additional information.
This can be easily translated into programming code where you adopt the
other approach, placing content placeholders in logic.
The problem comes to an end if we can design a sufficiently abstracted
"display logic" taglib and insert content placeholders. Otherwise, we
are back to the problems that Jeremy identified, which can be expressed
as "taglib" inflation.
Now, is Jeremy's "logic:" taglib such a abstract "display logic" taglib
where content placeholders are the <then> elements?
It might well be.
I honestly can't come up with nothing more declarative than
choose/when/otherwise.
> Our current situation is that we have about 50 separate pages like this,
> each with their own set of display logic and negotiable content.
>
> Our first approach to solve the problem gave us an approach that was easy
> to implement, but very unscalable. We had to write one StyleSheet for each
> XSP Page!!
Yes, this is clearly too much for such simple things.
> We had no where else to handle the display logic ... apart from XSLT,
> especially if we want the content easily available for change.
I totally understand this, yet... I won't be honest if I said I don't
feel some danger in this approach.
> >Do we want to create a scripting language using XML as a syntax? why? I
> >see this as FS big time!
>
> I think that for most patterns of development, it is indeed FS.
> I do understand your concerns.
>
> That is why I wrote to you and the Dev list about this, it provides a way
> of messing up the simple clean SoC pattern, it is a poor example ....
> however it is one we need to use in our circumstances (I believe).
>
> What worries me (the same as you) is that people will use the Logic TagLib
> inappropriately, thereby muddying the waters so to speak.
Yes, but this is why the Dev list exists: we can't stop people from
doing bad hacks on their own, but at least, we can make sure the hacks
aren't distributed with the package.
> That is why I am unsure as to whether I should contribute such a
> specialised TagLib with Cocoon, people may use it when they really don't
> need it, just because it is there, thereby messing up the clarity of SoC.
After the above analysis, I don't believe that having a conditional
choose/when/otherwise taglib necessarely breaks the SoC model, it just
blurs it in a range where content and logic aren't so well separated or
such a separation could be more harmful than useful.
But calling it "logic" might be too much... might call for procedural
extentions such as <foreach> and stuff like that.
> >The above should be written as
> >
> > <mylogic:do-something>
> > <request:get-parameter name="blah"/>
> > </mylogic:do-something>
> >
> >which should take into account all the errors. What about the error
> >string? Right, it should be the writer's concern so we place it here
> >
> > <mylogic:do-something>
> > <mylogic:message name="empty-param" xml:lang="en">
> > The request param is empty.
> > </mylogic:message>
> > <mylogic:blah>
> > <request:get-parameter name="blah"/>
> > </mylogic:blah>
> > </mylogic:do-something>
> >
> >and the contract with the document writer is simply the schema that
> >"mylogic" namespace has.
> >
> >So, general anti-pattern: when you see <if>, <else>, <for> or even worse
> ><goto> beware: you are turning a declarative syntax into a procedural
> >semantic. And yes, even XSLT is somewhat too procedural in many parts.
> >
> >Disclaimer: this is my personal opinion only and I have no voting right
> >at this moment so you decide what to do.
> >
> >My feeling is that people will start small and end up asking for an XML
> >rewrite of their favorite programming language, which is pretty scary,
> >don't you think?
>
> Yes, this worries me too.
>
> If you get the time, please look at the sample page I have enclosed
> (display.xml). This is probably one of the simplest pages on the site, it
> displays a single "Offer". But you see it has to display it differently
> depending on who made the offer, were they "cloaked", are different parts
> of the offer "negotiable"? etc. etc.
>
> You'll see it is sent the "id" of an offer to display, it retrieves the
> offer bean and outputs specific properties of the Bean to XML within named
> "blocks" (layout regions on pages).
>
> What this new pattern allows us to do, is to share stylesheets between
> multiple XML pages, because the XSLT no longer needs to have specific
> fine-grained logic inside anymore.
Which is indeed a better design, I concur.
> I appreciate the time you have taken to respond to this.
No problem.
So, at the end, if I could vote, I'd be +1 in the inclusion of such a
"conditional" taglib in the distribution, but if and only if this is
intended for conditions only and the semantics are not redundant when
unneeded.
Anyway, in all cases, this is just a taglib, it doesn't pollute the
Cocoon model in any way. One thing: write a document to explain why this
taglib can be abused and pages become more expensive to maintain in the
long run if carefull design is not applied.
Hope this helps and sorry for the length :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: RFC: Logic TagLib
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> Dear Cocooners,
>
> I develop XSP TagLibs, as part of my work on the CRUDLET project.
>
> <http://www.crudlet.org>
>
> We have developed a draft proposal of a TagLib for handling "content
> logic" for webapps; to allow contextual content selection logic to be
> encoded in an XSP page without the user having to write Java Code
> inside <xsp:logic/> tags.
>
> This is something that was critical for our project to allow us to
> develop in a more scaleable way to the techniques we are using now.
>
> The Logic TagLib was designed to be generic it has no dependencies on
> the CRUDLET project, it was always intended to be contributed to
> Cocoon.
>
> We invite all interested parties to read and comment on the proposal.
>
> <http://www.crudlet.org/logicTaglib.html>
>
> I understand that some people may find this controversial .... I am
> not too worried, we know it is something we need ;) but I am
> interested in your opinions and I am totally prepared to alter the
> specification, or to not incorporate it into Cocoon or whatever,
> depending on the response.
>
> As a taster, here are two examples from the proposal:
>
> A simple test for equality between the value that arrived in the
> request parameter called "blag" and an empty String. If the parameter
> was empty, the TextNode "The request param is empty" is output to the
> parent element of the <logic:if/> tag; otherwise there is no output.
>
> <logic:if>
> <logic:test op="eq">
> <logic:arg><request:get-parameter
> name="blag"/></logic:arg>
> <logic:arg/>
> </logic:test>
> <logic:then>The request param is empty</logic:then>
> </logic:if>
I'll be honest: I don't like XMLized scripting languages as a general
rule.
It blurs the separation of concerns: who is going to use this syntax? a
programmer? a document writer?
Having a procedural programming language included into your page as
another namespace appears more elegant than having a scriplet or
something like that, but it's nothing different conceptually.
Cocoon should aim at keep separation well defined and avoid unnecessary
blurring.
Let's keep the example above: it is the programmer concern to handle the
error case where the request parameter is empty, *NOT* the
document/template writer's.
Do we want to create a scripting language using XML as a syntax? why? I
see this as FS big time!
The above should be written as
<mylogic:do-something>
<request:get-parameter name="blah"/>
</mylogic:do-something>
which should take into account all the errors. What about the error
string? Right, it should be the writer's concern so we place it here
<mylogic:do-something>
<mylogic:message name="empty-param" xml:lang="en">
The request param is empty.
</mylogic:message>
<mylogic:blah>
<request:get-parameter name="blah"/>
</mylogic:blah>
</mylogic:do-something>
and the contract with the document writer is simply the schema that
"mylogic" namespace has.
So, general anti-pattern: when you see <if>, <else>, <for> or even worse
<goto> beware: you are turning a declarative syntax into a procedural
semantic. And yes, even XSLT is somewhat too procedural in many parts.
Disclaimer: this is my personal opinion only and I have no voting right
at this moment so you decide what to do.
My feeling is that people will start small and end up asking for an XML
rewrite of their favorite programming language, which is pretty scary,
don't you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: RFC: Logic TagLib
Posted by Ross Burton <ro...@mail.com>.
> Using these
>
> >lte (less than/equal to)
> >gte (greater than/equal to)
>
> Do people prefer "LTE" to "LE" and "GTE" to "GE"?
IIRC, perl (and other languages) use "le" and "gt", so using the same
symbols would be a good idea, why bother using new symbols when existing
ones are good enought?
Ross Burton
Re: RFC: Logic TagLib
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 15:26 -0500 11/01/01, Berin Loritsch wrote:
>Jeremy Quinn wrote:
>
>> Dear Cocooners,
>>
>>
>> I develop XSP TagLibs, as part of my work on the CRUDLET project.
>>
>>
>> <http://www.crudlet.org>
>>
>>
>> We have developed a draft proposal of a TagLib for handling "content
>> logic" for webapps; to allow contextual content selection logic to be
>> encoded in an XSP page without the user having to write Java Code inside
>> <xsp:logic/> tags.
>
>First, let me say you did a good job.
Thanks
>Next, let me offer a few constructive criticisms.
Even better ;)
>I like the idea of conditional logic for a higher-level
>programming interface--but it seems so XSL centric.
This pattern was chosen on purpose for it's familiarity.
>I realize that for
>those of us who use XSL extensively, that we find very creative ways of
>making things happen. However XSL is also very verbose. This carries
>over to your logic logicsheet.
I agree, it looks very verbose, however when I actually write real pages
with it (to sample the language, it's not implemented yet) it does not seem
so verbose when it is negotiating real content as opposed to little strings.
>Many developers are migrating from something like JSP, ColdFusion, ASP,
>or something similar. I am more familiar with ColdFusion, so I will use
>that as an example:
OK, I am not familiar with these products.
>Colfusion allows illegal syntax, so I will give it in cfml and xml:
>
><cfif variable.foo eq "bar">
> <p>Foo is a Bar</p>
><cfelse>
> <p>Foo is not a Bar</p>
></cfif>
>
>Now the XMLised version:
>
><logic:if parameter="variable.foo" eq="bar">
> <p>Foo is a Bar</p>
> <logic:else>
> <p>Foo is not a Bar</p>
> </logic:else>
></logic:if>
I don't see this as being so flexible.
It cannot test values from source other than the ones it has been
pre-programmed to know about, request, session etc.
If I wanted to test the value returned by
<crudlet:var name="blah"/>
or
<crudlet:value-of property="SatPublicOffers.InsuredValueIsNeg" bean="Offer"/>
or
Some other TagLib (tm)
The logic engine would have to "know" about them.
>Both versions are IMO more readable. Here are the notes:
>
>the parameter is scoped (from CFML carry over) by different
>levels: variable, session, uri, form, application. I actually
>find this to be a bit too fine grained. It would be done better
>like this: request, session, variable (with variable being
>default scope).
>
>the operation is an attribute whitch is more readable to the
>average programmer. Possible attributes and attribute combos
>follow:
>
>eq (equals)
>lt (less than)
>gt (greater than)
>ne (not equal to)
Using these
>lte (less than/equal to)
>gte (greater than/equal to)
Do people prefer "LTE" to "LE" and "GTE" to "GE"?
>from to (between FROM and TO inclusive)
Nice idea, I might call this operator "range"?
>
>Now for the choose tag:
>
><cfswitch expression="form.type">
> <cfcase value="dogcow">
> This is a Dogcow.
> </cfcase>
> <cfcasedefault>It was non of the above</cfcasedefault>
></cfswitch>
>
>and in XML:
>
><logic:switch expression="request.type">
> <logic:case eq="dogcow">
> This is a Dogcow.
> </logic:case>
> <logic:default>It was none of the above</logic:default>
></logic:switch>
It looks nice and compact.
Hmm, my choice of putting everything (except the Operator) in Elements,
makes it more verbose, I agree, but it allows you to work with any value,
including dynamic values from arbitrary sources.
We would not be able to do the job, with your suggested pattern of TagLib,
unfortunately.
>This are more analogous to many more true programming languages.
>
>The expressions can become more complex--but would need more
>analysis than what I can lend here.
Thank you for your feedback.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: RFC: Logic TagLib
Posted by Berin Loritsch <bl...@apache.org>.
Jeremy Quinn wrote:
> Dear Cocooners,
>
>
> I develop XSP TagLibs, as part of my work on the CRUDLET project.
>
>
> <http://www.crudlet.org>
>
>
> We have developed a draft proposal of a TagLib for handling "content
> logic" for webapps; to allow contextual content selection logic to be
> encoded in an XSP page without the user having to write Java Code inside
> <xsp:logic/> tags.
First, let me say you did a good job. Next, let me offer a few constructive
criticisms. I like the idea of conditional logic for a higher-level
programming interface--but it seems so XSL centric. I realize that for
those of us who use XSL extensively, that we find very creative ways of
making things happen. However XSL is also very verbose. This carries
over to your logic logicsheet.
Many developers are migrating from something like JSP, ColdFusion, ASP,
or something similar. I am more familiar with ColdFusion, so I will use
that as an example:
Colfusion allows illegal syntax, so I will give it in cfml and xml:
<cfif variable.foo eq "bar">
<p>Foo is a Bar</p>
<cfelse>
<p>Foo is not a Bar</p>
</cfif>
Now the XMLised version:
<logic:if parameter="variable.foo" eq="bar">
<p>Foo is a Bar</p>
<logic:else>
<p>Foo is not a Bar</p>
</logic:else>
</logic:if>
Both versions are IMO more readable. Here are the notes:
the parameter is scoped (from CFML carry over) by different
levels: variable, session, uri, form, application. I actually
find this to be a bit too fine grained. It would be done better
like this: request, session, variable (with variable being
default scope).
the operation is an attribute whitch is more readable to the
average programmer. Possible attributes and attribute combos
follow:
eq (equals)
lt (less than)
gt (greater than)
ne (not equal to)
lte (less than/equal to)
gte (greater than/equal to)
from to (between FROM and TO inclusive)
Now for the choose tag:
<cfswitch expression="form.type">
<cfcase value="dogcow">
This is a Dogcow.
</cfcase>
<cfcasedefault>It was non of the above</cfcasedefault>
</cfswitch>
and in XML:
<logic:switch expression="request.type">
<logic:case eq="dogcow">
This is a Dogcow.
</logic:case>
<logic:default>It was none of the above</logic:default>
</logic:switch>
This are more analogous to many more true programming languages.
The expressions can become more complex--but would need more
analysis than what I can lend here.
>
>
> This is something that was critical for our project to allow us to
> develop in a more scaleable way to the techniques we are using now.
>
>
> The Logic TagLib was designed to be generic it has no dependencies on
> the CRUDLET project, it was always intended to be contributed to Cocoon.
>
>
>
> We invite all interested parties to read and comment on the proposal.
>
>
> <http://www.crudlet.org/logicTaglib.html>
>
>
> I understand that some people may find this controversial .... I am not
> too worried, we know it is something we need ;) but I am interested in
> your opinions and I am totally prepared to alter the specification, or
> to not incorporate it into Cocoon or whatever, depending on the response.
>
>
>
> As a taster, here are two examples from the proposal:
>
>
> A simple test for equality between the value that arrived in the request
> parameter called "blag" and an empty String. If the parameter was empty,
> the TextNode "The request param is empty" is output to the parent
> element of the <logic:if/> tag; otherwise there is no output.
>
> <logic:if>
> <logic:test op="eq">
> <logic:arg><request:get-parameter
> name="blag"/></logic:arg>
> <logic:arg/>
> </logic:test>
> <logic:then>The request param is empty</logic:then>
> </logic:if>
>
> This is a typical use of the <logic:choose/> tag whereby multiple
> <logic:when/> clauses are evaluated until one of them returns something.
> If none of them returned anything, the contents of <logic:otherwise/> is
> output. There should be one or more <logic:when/> clauses and only one
> <logic:otherwise/>. The equivalent forms of nesting available to the
> <logic:if/> tag will also work with the <logic:choose/> tag.
>
> <logic:choose>
> <logic:when>
> <logic:test op="eq">
> <logic:arg><request:get-parameter
> name="type"/></logic:arg>
> <logic:arg>fish</logic:arg>
> </logic:test>
> <logic:then>This is a Fish</logic:then>
> </logic:when>
> <logic:when>
> <logic:test op="eq">
> <logic:arg><request:get-parameter
> name="type"/></logic:arg>
> <logic:arg>dogcow</logic:arg>
> </logic:test>
> <logic:then>This is a Dogcow</logic:then>
> </logic:when>
> <logic:otherwise>It was none of the above</logic:otherwise>
>
> </logic:choose>
>
>
>
>
> This will get implemented over the coming weeks.
>
>
>
> Let me know what you think, (but please read the whole thing first ;)
>
>
> Thanks
>
>
> regards Jeremy
>
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>