Reinhard Poetz dijo:
With Groovy the (2) will be easier.I'm aware of the fact that there are many ways in Cocoon. I think that we as community should give clear advice what's in our opinion the best way. If I'm asked I say:
1. Enterprise Level ---> O/R-mapping, EJB
2. Simple Database Applications with CRUD (create/update/delete)
---> Flowscript and Database Component
3. Publishing ---> SQLTransformer
I think (2) can be also be used with O/R mapping tool. Not sure what the DB component is. In fact (and with my respect to ESQL developers) why Cocoon will need to build another layer when there is OJB. Remeber OJB allow you to play at 4 levels:
A-PersistenceBroker - A very simple API to deal with DB. With DB transactions, but not object transactions B-OTM - Object Transaction Manager. The same as above + Object Transaction. C-ODMG D-JDO
In this way OJB is not exclusive for big leaguers. You can use OJB in
minor applications too.
I'm aware of that. But do we give this our users as advise for *all* cases? Don't forget what a user has to learn in order to implement an application with Cocoon:
- Setting up Cocoon - learn about the concepts of sitemap & pipelines - learn XSLT - learn Flowscript (Javascript) - learn how to mange a DB - learn how to manage an O/R-Mapper + learn Java (for the objects) - learn CocoonForms and how to bind them to Java objects
In my opinion this is the way to go but it's *not* an easy way.
Following this I don't see the need for
a. calling DB from within Flowscripts
You mean direct JDBC? Hmm.. I don't like the idea, but here Groovy can
take the role a lot better than Javascript. Note, Groovy has built in SQL
support and that is good.
Yes, I don't like the idea too. It's good for prototyping but I wouldn't write my applications with direct DB calls from within the flow layer. I don't want direct DB calls from within Groovy as Flow language *also* because this mixes concerns!!!
b. code CRUD in templates (Groovy, JXTemplate, ...) and XSP
I will use this combination for (2) it is more powerful than the proposed.
Also note, JXTG is useful in combination with CForms. It allow you to easy
make a dynamic listbox or show a simple list report for users. It is
really useful have JXTG at hand.
I really like JXTG but for now it has *no* direct DB access. You have to pass the objects to the pipeline within cocoon.sendPage*() and this is good!
and not sure about
c. DatabaseActions. There might be reasons to use them if people don't
want
to learn Flowscript but I'm not sure if we should recommend it.
And let the user base start ranting us? I think is our obligation to
support "stable" blocks. The same apply to Avalon components. I think
there is a lot of people that use this Actions and we cannot drop support
from one day to another. The worse is that this APIs are considered
stables. Then we need to live with them for a while. This is the same case
as XSP.
I *don't* want to *drop* support for things we declared stable but what I want is clear *recommendations* - nothing more.
I already said in several mails that we should reduce the recommended options:
1.) Use O/R-mapper if possible
2.) if you only have publishing tasks use the sqlTransformer
3.) If the learning curve for an O/R-mapper is too steep for you take ????
(In my opinion this is a simple DB-component as described below)What I want to tell all users clearly is that they should avoid writing SQL-statements. Integrating SQL in applications is the start of a maintainence nightmare and IMHO we should clearly warn them using XSP, Groovy or any other templating system requiring you to write SQL *into* the code. Once again, I really like e.g. JXTG but it should *never* contain SQL statements. IMO the same is true for Groovy scripts.
You also asked how the DatabaseComponent which I'm thinking of could work - here an example:
function myDBFunc() {
var myDBComp = cocoon.getComponent("myDBComp");
myDBComp.setMapping("mappingFile.xml");
myDBComp.add("tableSet-A"); // tell the component which tableset to
use
cocoon.sendPageAndWait("blabla", {});
}
I will prefer OJB people to make what they do the best. Is worth to make
another DB support in Cocoon anothe propietary API? AFAIK, Cocoon is the
"glue" for webapp needs. And here we will go to another area. Also, why
reinvent the wheel again?
This wheel has already been invented using the *DatabaseActions. Don't forget that they have one big advantage compared to O/R-mapper: You don't have to learn Java to use them!!! (see comments on learning curve). Therefore I think they are an interesting canditate.
Maybe the DatabaseComponent should support reading operations too.
The question is whether we don't duplicate the efforts of e.g. OJB with
this approach? The only difference is that you don't need Java objects ...
-- Reinhard
