cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: An idea - transformer logicsheets.
Date Mon, 02 Feb 2004 04:59:38 GMT
Steve Krulewitz dijo:
> Stefano Mazzocchi wrote:
>> We are slowly deprecating server pages in favor of more MVC+ approaches
>> (that is: flows control + business objects + view templates)
>> In Cocoon 2.2, XSP will probably move to their own block and removed
>> from the core (this means they will still be supported, but not
>> considered core technology and not advocated as "the way").
> I still find the esql taglib to be a very useful and easy way to go from
>   SQL query to an XML document.  If xsp is deprecated, the only other
> way to easily do this is the SQLTransformer, but it is lacking many of
> the features that the esql taglib has.

Yep. ESQL is the best thing in XSP. In my own experience, ESQL is good for
very small DB webapp. When you are beyond small webapp, the ESQL code
start to be complex and some features are really complex or dificult to
solve. We have some XSP pages with ESQL that currently we would don't want
to review or change because of the complexity. We made applications of
both types (original and modular DB actions + ESQL using XSP).

Please note, I am talking based on my own experience. It is not the
official position of Apache Cocoon:

This is why we started to find another way to interact with DB in Cocoon.
While we tried to find a better solution, we noted the efforts in Flow and
Woody development. We started to follow Flow in the list early last year
and then in the mid of the last year Woody comes to scene. The combination
of both gives us the idea it would fill the Controller (Flow) and the View
(Woody) of MVC. Then of course the gap was on the Model. What to use on
the Model? Well, some people recommended Hibernate and OJB. After
reviewing both of them we choosed OJB, because it was easier to us and is
Apache licensed that means the integration with Cocoon will be easier.

To me OJB is the succesor of ESQL. We are currently developing 2
applications with OJB+(Woody+JXTemplate)+Flow (MVC) and we are very happy
with the results. It is really amazing, finally we can talk seriously
about a true SoC.

Our current development of the model for us is:

1-Design the DB using Druid -

2-Generate with Druid: SQL script schema, Java JDO Beans, OJB O/RMap and
HTML documentation of the Database. Build a JAR file with JDO Beans.

3-Build some handler in Java for Woody forms. This handlers allow mainly
the basic operations with database by manipulating the Java Beans.

Step 1 is as fast as you can model your database in a graphical interface.
It is really very easy. Druid can generate scripts for many DB including
PostgreSQL, MySQL, generic SQL, Oracle, and others.

Step 2 takes maybe 5 minuts or less! :-D

Step 3 takes a little more. We are trying to find some commons aspects to
find a way that allow some kind of automatization of these step. The main
problem here is because the Handlers manipulates the beans that Woody show
to the user. In that sense every Handler directly depends on the Woody
forms or in the results we need to show in a JXTemplate.

We are thinking in this issue while we are currently programming this step
by hand. Anyway this is far more manageable than the XSP approach. I think
in the archives are mails of the steps we did while we tried to find the
current approach.

> Maybe adding support for iterating through ResultSets in a JXTemplate
> might make this easier to do from flow?  Or is this already possible?

Hmm..., but the problem is that AFAIK, JXTemplate is part of the View in
MVC. This is why I am not sure if it would be a good idea to insert DB
support at JXTemplate level.

Best Regards,

Antonio Gallardo

View raw message