cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: RFC: Logic TagLib
Date Thu, 18 Jan 2001 17:18:33 GMT
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.


>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

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

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

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


>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

   <>     		 <>
    <phone:+44.[0].20.7737.6831>        <>

View raw message