Reinhard Poetz dijo:
> 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
With Groovy the (2) will be easier.
>
> 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.
> 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.
> 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.
> 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.
> 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?
> 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 ...
Best Regards,
Antonio Gallardo
