cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [Design] JXTG 2.0 (Just say no!)
Date Thu, 02 Dec 2004 11:37:34 GMT
Miles Elam wrote:

> Ummm...  Hold on second while I don my flame-resistant underwear.
>
> Okay folks, why are we making tag libraries/interfaces *at all*?

Take a look at the implementation of JXTemplateGenerator, and the 
implementation of ESQL and then on the implementations of a couple of 
the various transformers that interpret different tag languages. Not 
that pretty. They where certainly not easy to write, they are not easy 
to read and they are even harder to maintain. Neither the less they do a 
good work although some of them could need to be updated to reflect our 
current ideas about how to do things.

The main reason to implement tag libs from my POV is to be able to 
refactor things like JXTG and ESQL as taglibs so that they become easier 
to support and improve. And so that we can avoid those endless 
horrendous listings of the methods in the SAX interface as soon as some 
one want to let a tag doing something.

Concerning interfaces for tag libs: they are important as they controll 
what you can do (and what you are forbidden to do) from you tags. The 
design of the intefaces will also effect how easy it eill be to write 
readable tags.

>   I mean it.  I feel like a lemming being driven off a cliff.

Its just web server code if you avoid using any taglibs in life support 
system or stearing systems in aeroplanes, your physical safety shoudn't 
be affected ;)

<snip/>

> Why tag libraries?  To deal with the excessive code in the markup.

No, the reasons are those that I gave above: maintainabillity for those 
"taglibs" that we allready have in Cocoon.

Then I'm certain that some users are going to do things that I consider 
ugly and counter productive with the help of taglibs. But people are 
creative so someone is going to find a missuse for any technology.

>   If you really need code in markup for your corner case, tag 
> libraries aren't going to help the situation much.  You need code. 

> So here we stand discussing how to go back to big balls of tag library 
> mud.

We are not! From my POV we are going to reimplement the declarative and 
side effect free parts of JXTG, ESQL, the CForms tags and possibly other 
_declarative and side effect free_ tags.

>   We have a glimpse of better things with Flow.

Sure flow logic, business logic binding and side efects in flowscripts 
and side effect free presentation oriented stuff in (e.g.) template, 
clear SoC.

>   Why aren't we examining that model for further direction?  Why are 
> we going backwards?  Arbitrary Java code executing in the markup but 
> with a prettier face?  Great.  I'm so happy, I could eat the six month 
> old leftovers rotting in my friend's tupperware.

You could spend some of your creativity on finding reasonable contracts 
on what we want to be able to do in template instead of just ranting.

> CAN' T WE COME UP WITH A BETTER IDEA!?!  There are some really smart 
> people on this list.  C'mon!

We are happy if you find and maybe even implement a better idea. 
Requring others to comme up with smart ideas are like requiring them to 
implement the features that you need or write the documentation you 
would like to have:

Don't ask your open source community what it can do for you, ask 
yourself what you can do for your open source community!

> What have tag libraries been used for?
>
> 1. A macro language
> 2. Data generation
> 3. Data formatting
> 4. Backend processing
> 5. Making programming languages out of markup
> 6. Data replacement
>
> Let's go down the list.
>
>        1. A macro language
>
> XSLT or any of the other markup transformation syntaxes can handle 
> this.  No code or tag API needed.  STX: an easy-to-use syntax enabling 
> a SAX stream with a minimal memory footprint.  Side effect-free.  
> Highly cacheable.  The cached SAX events for JXTemplateGenerator are 
> put in the cache for future use -- same story with a 
> JXTemplateTransformer or any JXTemplate* successor or whatever.  
> Nothing lost by using a simple transformation language.  The best 
> part?  It's simple.

Honestly, have you followed the discussion that my design document was 
based on? Everyone that ever have tried to fix something in (or tried to 
understand) JXTG seem to agree about the need of refactoring it, to make 
it supportable. I have given some suggestions about how to achieve this, 
better ideas are always welcome.

I would prefer to use XSLT or XQuery as a template language, although it 
doesn't solve how to handle things like ESQL. I spent some effort on 
doing that one and half year ago 
http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2, 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998241710064&w=2, 
http://marc.theaimsgroup.com/?t=105016536400004&r=1&w=2 and
http://marc.theaimsgroup.com/?t=105178446600003&r=1&w=2.
But it is quite complicated although possible to make an XSLT or XQuery 
processor read Java bean structures in an efficient way. Saxon that 
would be the most attractive choice is MPL 1.0 that was supposed to be 
incompatible with APL. And then Christopher implemented JXTG which 
solved the most important requirements.

>        2. Data generation
>
> Raise your hands.  Let's see who you are that still thinks after all 
> that we've learned from web development history that 
> <esql:execute>SELECT * FROM MYTABLE WHERE COLUMN1 = 0</esql:execute> 
> is a good idea and the best we can come up with?  I admit that I was 
> one of "those" people that was trying to get a standard relational 
> database API in Flow.  So wrong.  SO WRONG.  I would like to thank the 
> developers on this list for their insight and wisdom on this point.
>
> If you are savvy enough to write a Java class that implements the Tag 
> interface, you are certainly smart enough to write a POJO for use with 
> Hibernate (or whichever object persistence mechanism you prefer).  In 
> fact, the way things are going and with the tools being made 
> available, the Tag interface is *harder*.  And an implementation of 
> Tag verses a Javascript object or data structure?  The difference in 
> complexity level isn't even funny.

You are mixing things up. The ESQL like tags are written once by a Java 
savvy person and then they can be reused as often as wanted by people 
who are not, but who know SQL. I'm certain that object relational tools 
are very usefull if you when you build enterprise systems in Java. But I 
fail to understand why it would help anyone who don't to write simple DB 
reporting. Neither do I understand why people who use Hibernate etc have 
such strong urge to again and again inform the rest of us that they have 
found _the truth_ and that we should convert to _the right way_ 
immediatly to save our souls.

Personally I start to believe that the "apply OO enterprise design 
patterns on everything" attitude, is an anti pattern. Use scaleable 
methods when you need it and avoid the complexity from such methods when 
you do something simple. And if you need to scale your simple 
application, refactor it to use the enterprise patterns you need.

For many simple cases:
<esql:execute>SELECT * FROM MYTABLE WHERE COLUMN1 = 0</esql:execute>
is an excelent and easy to understand idea.

>      3. Data formatting
>
> Let's call a spade a spade here.  We've got how many variations that 
> need to be handled?
>
> boolean, integer types, floating point types, dates/timestamps, 
> strings, XML fragments, selection from limited choices (if 0, say 
> "none" -- if 1, say "one" -- if more, say "many"), and objects (which 
> are basically .toString() calls unless it has properties that are 
> plain old datatypes -- in which case you use the other handlers).
>
> That's what?  Seven different formatters?  Done.  Finished.  Do we 
> really need a tag library for that?  Make them reusable components 
> that transformers can use as needed.

Thats the idea, read 
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2. Hoppefully we 
can remove the need for data formatting tags.

>      4. Backend processing
>
> We don't like to admit it, but we've all wondered, "What if this 
> custom tag could trigger a cache invalidation or do some workflow 
> or..."  Bad idea.  Bad idea.  Backend processing in your markup 
> template is a horrible idea.  Do it in an action or better yet in Flow.

Sure.

>      5. Making programming languages out of markup
>
> <foo:if>, <foo:for-each>, <foo:eval>, etc.  Why the foreplay?  If 
> you're gonna write a programming language, at least have the decency 
> to not base it on markup.  These aren't really different from saying
>
> <% if (test.isTrue()) { %>
>   <foo/>
> <% } %>
>
> or XSP's
>
> <xsp:logic>
> if (test.isTrue()) {
>   <foo/>
> }
> </xsp:logic>

IMNSHO, this is totaly wrong. As soon as you have sequences or 
recursively defined data structures from business logic, e.g. lists or 
trees, you need conditionals, iteration constructs and recursively 
applicable templates. Say that you get an item list, a menu tree or a 
folder structure e.g. from your business layer, how are you going to 
render them without such control structures? Adding side effects, write 
access to your business model or Cocoon environment or even allowing 
full fledged Java constructions, is something completely different.

In a template language you need the same controll structures as in XSLT, 
but they must be applicable on other input (read only) data structures 
than XML, Java beans or SQL row sets e.g.

> IMO constructs like this should be context-dependent on the task at 
> hand.  For example, wouldn't it have been easier if instead of
>
> <jx:for-each var="person" items="${people}">
>   <jx:if test="${person.name != 'Mean Mike'} ">
>     <friend>${person.name}</friend>
>   </jx:if>
> </jx:for-each>
>
> you had
>
> <friend jx:context="${people}" jx:test="${name != 'Mean 
> Mike'}">${name}</friend>
>
> Same thing.  Not a programming language though.  Data injection 
> tailored to the task at hand.  This is the problem domain that 
> JXTemplateGenerator is made to solve.

My intension is to make "template" an open framework as well as an 
application, so that you can reuse parts of it for developing own ideas. 
So if you want to develop something like what you suggest above you can 
think about and discuss what mechanisms you need for implementing that. 
I focus on taglibs as it is a well known, understand and easy to 
implement technology.

> What is the for-each doing?  Setting a scope -- a context.  Look back 
> in the templates you've made.  How many <jx:if> elements wrapped more 
> than one element?  I have found in my general usage that well over 90% 
> of the time it's just the one child element.  And those 
> <jx:chose/when/otherwise>...  Be honest, how many times have you used 
> that for data formatting rather than structural changes to the 
> markup?  Listing stuff like "yesterday" or "today" or "last week" 
> instead of the raw date.  That's a boatload of markup to do what 
> amounts to a java.text.ChoiceFormat method call.
>
> If it's that complex, why isn't it reflected in your data model 
> instead of your markup's wannabe programming language?
>
>      6. Data replacement
>
> And here we come to the meat.  This is where the I18nTransformer does 
> its magic.  This where JXTemplateGenerator does its thing.  One hit 
> wonders where the markup has been altered to fit the problem at hand, 
> not the general definition of a tag library.  Where does the following 
> I18nTransformer example fit in?
>
> <input type="submit" value="Submit" i18n:attr="value"/>
>
> It can if all it does it translate <foo:i18n-submit/> to the above for 
> "real" processing.  Stylesheet.
>
> Data injection.  That's what custom markup is really good for.  It's a 
> domain-specific problem.  Tag libraries are for general case 
> problems.  But the general case is already handled by the existing 
> transformers' API.

Again take a look at the implementations of transformers that interprete 
tags or on the sitemap complexity when you want to use tags from several 
domain-specific areas. The  transformers are quite complex beasts and 
you need very detailed knowledge in using SAX to write them besides your 
domain specific knowledge.

It would be much easier to implement and support such stuff as taglibs.

>           -------------------------- o0O0o -------------------------
>
>
> So what are the use cases that require tag libraries?  More 
> specifically, what are the use cases that require tag libraries that 
> will be made cleaner by skipping XSP?
>
> What would I prefer?  Keep XSP as it is.  It's shite, but it's 
> powerful shite.  It's for the edge; those pesky corner-cases that 
> refuse to go away; the last 1%.
>
> * XSP is Cocoon's mod_rewrite. *

We are not going to depricate XSP anytime soon, use what you want.

> Don't code around mod_rewrite.  Let it be the method of last resort.  
> Find a model that allows the logic, data structures and code to live 
> elsewhere.  Leave data injection and formatting to the template 
> generator/transformer.  Look at Flow and find something like it.  
> Maybe not exactly Flow, but a lot closer to it than the world of 
> ASP/PHP/JSP and tag libraries.

Look, if you use a tool where taglibs is your main instrument for using 
all kinds of problems you are certainly going to misuse it. But from the 
fact that it is bad idea to use taglibs for everything you cannot infer 
that it always is bad. IMO it is very useful for the kinds of cases I 
have described  earlier.

> I would prefer something like
>
> <Cats xmlns:data="http://org.apache/cocoon/data">
>   <Cat data:context="${cats}" name="${name}" sex="${sex}" age="${age}"/>
> </Cats>

As allready said, if you participate in the development of template and 
you flesh out some more details about how it is supposed to work, it 
might be possible to allow such constructions in "template".

<snip/>

> Sure, macros can alleviate this.  But macros are band-aids on a 
> usability/design defect.  This talk of macros and tag libraries I 
> think has more to do with our frustrations with the current models 
> than actual demonstrated need.  So instead of a discussion about how 
> the tag library API should be defined, why not make the simplest 
> interface for the outside world first.

Please suggest such an interface.

>   And only after that's done, talk about implementation details like 
> tag libraries.

It's based on some rather lengthy email discussions please re-read the 
archives http://marc.theaimsgroup.com/?l=xml-cocoon-dev&r=1&w=2 ;) We 
cannot discuss lofty ideas for ever, sooner or later it is time to 
actually make chices, design and implement things. There will allways be 
better ideas in the future (or some otherware), but in the end of the 
day you must see what your current set ideas leads in practice and learn 
from that.

> Do you logic in a real programming language.  When you finish, pass 
> the result to the template for styling/formatting.
>
> Or am I alone in these feelings?  Pretty interfaces being stuck in the 
> middle of big balls of mud!

I agree with many of your requirements, but I think that your 
interpretation of what we are trying to acomplish is rather unfair. 
Anyway, it is important that we are clear about what the big picture is 
and not only about the technical details. And your questions (and 
ramblings) give us a good oportunity to find out about that.

/Daniel


Mime
View raw message