cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Modular database component
Date Tue, 20 Apr 2004 08:38:36 GMT
Antonio Gallardo wrote:

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

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


Mime
View raw message