cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [Design] JXTG 2.0 (Just say you're sorry!)
Date Thu, 02 Dec 2004 23:35:53 GMT
<snip type="a very interesting discussion"/> let me chime in

Having spent quite some time with XSP and ESQL
(and friends) I have to admit: XSP can become a
PITA. But usually because of taglibs (
already mentioned in the thread)

The very basic XSP is not much more but using
java as your templating language. Well, the
thing is java and XML just don't mix very well.
...but that's just a question of the syntax.

Yes... I do think that taglibs are the evil
of XSP. The compilation part ...not nice but
more or less depends on how you deal with it.

The good and the bad is that XSP gives the
full power of java. ...full access to every-
thing available in the jvm.

> But is ESQL is the best choice?  Data input becomes a big deal when
> you use ESQL for output and then a stream generator combined with 
> transformation combined with sqltransformer combined with...
> I'm a big proponent of "make the better decision easier than the
> worse decision."  Quick and dirty, ESQL works.  For limited obscure
> cases, ESQL is great.

Hm... I am wondering what you mean by the big
deal of the input. Fact is that ESQL has some
very unique features. ..that are needed in not
so obscure cases.

I might not be up-to-date with object mapping
frameworks but even if you say that they all
support query time row limitations tables
of a million+ rows are still page-able without
having the data shuffled across the network by
the stupid JDBC driver implementation ...there
still is the question if *you* do the database
design. Mapping to a bad designed database can
be also be no big fun.

Anyway what I was trying to say ...sometimes
SQL can be a very concise syntax for what your
framework might make even more complicated.
Sometimes... just depends!

I think a much bigger problem of ESQL (and also
the SQLTransformer) is the time when the database
processing is happening. ...just too late.
Inside the view bring the MVC up again.

It should better be inside the controller.
Which would be most likely flow. But noone
wants to pollute the flow with SQL statements
(does someone)? ...that's the real beauty of
flow with a relational mapping IMHO.

my 2 cents

View raw message