cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: RFC: Logic TagLib
Date Fri, 12 Jan 2001 21:20:28 GMT
[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
   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
> 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

Allow me to make a simple abstract analisys over logic/content

There are two possibilities to fully separate content and logic

1) place logic placeholders into content


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

 <block name="instructions">
    <logic:test op="eq">
      <crudlet:value-of property="SenderUsername" bean="publicOffer"/>
      <crudlet:value-of property="Username" bean="UserBean"/>
     <p>[a bunch of text]</b>
      <logic:test op="eq">
        <crudlet:value-of property="IsCloaked" bean="publicOffer"/>
        Remain Anonymous
       [some other text]
    <p>some additional information</p>

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

> 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
> ><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

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.
<>                             Friedrich Nietzsche

View raw message