Daniel Fagerstrom wrote:
Torsten Schlabach wrote:
Hi all,
I have done some work with and on SQLTransformer recently and came
across
one fundamental question, that I would appreciate some views on.
...
In situations, where you would want to build a more generic data
browsing
application that makes use of the database metadata to extract
information
about the data (in ohther words: you don't know the fieldnames
upfront) it
would be much cleaner if the XML generated would read:
...
This have been discussed for years but not resulted in much code. What
you ask for can rather easily be done in ESQL (an XSP library), IIRC.
But XSP is hard to maintain and develop new functionality in due to
its design, so we don't recomend people to use it anymore.
There have also been various proposals to move ESQL functionality to the
SQLTransformer, but no action.
One camp have been so entusiastic about OR tools that they don't think
that there is a need for things like the SQLTransformer at all,
Hibernate should be used instead.
I will suggest OJB instead - http://db.apache.org/ojb/.
I was working on a hibernate the last weeks and I need to say that I
prefer OJB. Here 2 samples:
1-When using a java List for a collection inside a bean, in Hibernate
the table need an additional field to manage the order of the table
rows! What is that?
2-I don't want in my database more fields than what I need, so let
replace the Java List witth a Java Set --> then I meet a new problem:
cforms binding use jxpath and jxpath don't work with Sets. jxpath throws
an Unsupported Operation Exception! Boom!
I wonder how people using hibernate deal with this situations. The 1st
shows me a poor database desing and the second a restriction to use
cforms at all! In my case I prefer to stay on the OJB side and stayt
away of this silly problems.
When we refactored JXTG, I designed it in such a way so that it should
be easy to add new sets of instructions to it, I did this in particular
to be able to reimplement ESQL as instruction tags usable within JXTG.
Then we had a long debate where some people where strongly against
allowing such things in JXTG, see
http://wiki.apache.org/cocoon/Templates#head-21328543e917fa0537016fe30cb85c3ee42fc68a
for links to the discussions.
Yep. We believe JXTG is not XSP. ;-)
In http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110207408722028&w=2
Sylvain give some ideas about how to replace ESQL and in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110202403115200&w=2
Stefano gives his view. Both suggest, from somewhat different
perspectives that the query should be prepared in the controler (e.g.
flowscripts) and that the result set should be itereated through in the
view (e.g. JXTG).
I agree with the Stefano POV. This is the way I an working and believe
me my
Now, having written plenty of webapps that use tons of queries performed
in the SQLTransformer, I'm of the opinion that the SQLTransformer is a
rather convenient way of handling low to intermediate compleity SQL
applications. And it would be even more convenient to embed the queries
in JXTG. And it would be fairly easy to implement the needed
instructions.
See the Stefano's solution above.
I have been developing applications with Cocoon and OJB for 2 years now.
IMO O/R mapping offer far more features than SQLTransformer and . I hear
people telling there is too much work to create and O/R mapping. IMO
this is FUD. In fact a O/R mapping need less work or at least the same
amount of work or less in more complex applications. here I explained
how easy is to work with this an OR mapping:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107569798213119
More on this here:
http://wiki.apache.org/cocoon/Templates?action=fullsearch&context=180&value=OJB&fullsearch=Text#head-21328543e917fa0537016fe30cb85c3ee42fc68a
--- o0o ---
To sum up, I find it rather unsatisfying that we don't have "modern" and
convenient solution for simple SQL reporting. I'm certain that OR tools
are fantastic in some cases, but they are IMO overkill for simple
reporting applications. Both ESQL and the SQLTransformer are somewhat
unconvenient to use, although in different ways.
Please, never understimate the power of a O/R mapping tool! ;-)
IMO we should either provide JXTG instructions for SQL reporting or give
some kind of support and examples on how to use SQL with query
preparation in the controler and report construction in the view layer,
(following Sylvain's or Stefano's sugestions).
The 1st option is not a solution is only a workaround. The worse is that
I see that as a return to the old complexity and mix of concerns. Seems
to be not a good idea.
I prefer the 2nd option: give some kind of support and examples on how
to use SQL with query
preparation in the controler and report construction in the view layer.
Maybe someone in GT2005 can do a presentation on this topic. I remember
that Bertrand showed some of his work related to this way of doing
things: http://wiki.apache.org/cocoon/GT2004Bertrand
Best Regards,
Antonio Gallardo.
