cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 08:26:33 GMT
Reinhard Poetz dijo:
> Antonio Gallardo wrote:
>
>>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.
>>
>>
>
> 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 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.

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.

> 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.

Best Regards,

Antonio Gallardo

Mime
View raw message