Reinhard Poetz dijo:
Antonio Gallardo wrote:
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.
We can add more to the list, but it is OK.
I think we need to define what kind of users we are targetting. I believe our targetted user is not too entry-level. Because if someone is trying to deal with a database we expect it is not the average excel user or yes?
And for some simple forms as many HTML books comes, no one solution in Cocoon will allow them even in the case of a 1 table database.
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 let the user base start ranting us? I think is our obligation toand 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.
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
I *don't* want to *drop* support for things we declared stable but whatstables. Then we need to live with them for a while. This is the same case as XSP.
I want is clear *recommendations* - nothing more.
As you pointed beffore, recommendations depend on the level of the user. The is no one size shirt to fit all people.
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)
Did you believe me if I told you I never used the SQLTransformer? I know it from the Carsten-Matthew book, but what I don't like was that in order to make some SQL constructions you will need to use the SQLTransformer more than once. It really make me go apart of that.
About DB Original and Modular Actions. I was a big fan before we had troubles because some SQL constructions was not allowed. We needed to define some worksaround to make them works and that makes the code ugly. This was the main reasons why we moved away of them. Again, I really respect the work of committer that did it. I think it was the best we can have at that time.
What I want to tell all users clearly is that they should avoid writing
SQL-statements.
+1
Integrating SQL in applications is the start of a
maintainence nightmare and IMHO we should clearly warn them using XSP,
+1
Groovy or any other templating system requiring you to write SQL *into*
the code.
Lets see us this, before issuing a opinion about that. At first sight, Groovy looks promising as a good candidate for filling list of data in combos or other really simple tasks. But not sure, maybe this is a dumb idea.
Once again, I really like e.g. JXTG but it should *never*
contain SQL statements.
+1
IMO the same is true for Groovy scripts.
Partially true. (see above). We need to see the really power of Groovy before issuing an opinion. It is too early for Groovy. Please allow us to test it and later we can discuss about that.
<RT> Groovy can also be seen as a hibrid between Javascript and Java. In that way instead of using 2 languages for FlowEngine + Model, we can use 1. </RT>
Some languges are discarded just because someone tell us it is bad and
sometimes later we realize the opinion was wrong. We really don't have
arguments to discard Groovy. Note, Groovy can also allow us to write the
businnes logic as it allow to interact with Java classes.
After reading this one question remains: What is the reason why are *you* interessted in Groovy and its SQL support? Which problem do you want to solve which can't be solved with OJB?
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.
Again, qestion here are:
1-User targetted audience
2-you can not do whatever with MDBA or MOA.
That's clear, that MDBA don't replace O/R-mappers at all. But there is a target audience which doesn't want to learn an O/R mapping tool for many reasons mentioned in this thread.
-- Reinhard
