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 - http://druid.sf.net 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
