Re: Modular database component

[Reinhard Poetz <re...@apache.org>]

Bertrand Delacretaz wrote:

> Le 19 avr. 04, à 10:17, Reinhard Poetz a écrit :
>
>> ...The best way integrating database support in Flowscript is using 
>> an *O/R-mapper*. If this is too complicated I would recommend a 
>> general database component....
>
>
> I don't know much about the ModularDatabaseActions, but would a 
> ModularDatabaseComponent be much more powerful or much easier to use 
> than a ScriptableDatabaseComponent?
>
> I'm thinking of something similar to the existing ScriptGenerator in 
> the BSF block, using Groovy scripts to let the user implement  the 
> details of database queries and result set formatting. I don't know 
> about what kind of interface you're thinking about for the database 
> component though, did you think about it already?
>
> I hope I'm not being too loud about Groovy, but when I see the 
> absolute coolness of the GroovySql syntax [1], combined with the 
> responsiveness of the Groovy developers, it is hard for me to refrain 
> from pushing it as hard as I can ;-)
>
> -Bertrand
>
>
> [1] http://groovy.codehaus.org/sql.html - look at the GroovyMarkup 
> example down the page, we're very close to having this in the BSF block
>
>
I have to think more about the API of this component but first I want to 
talk more about the background of my idea. I had several discussions 
with Alex Schatten and we came to the conclusion that, generally spoken, 
there are two database usage scenarios:

 1. Enterprise Level

 2. Simple database applications
    Usually very small projects where you need only a few 'interactive' 
pages.

If you are familiar with O/R-mapping tools I always recommend them, also 
in scenario two.

The question is, how do we deal with scenario two if the user is _not_ 
familiar with e.g. OJB. I think O/R-mapping is rather straight forward 
but IMO there are users who don't want to write programmes at all. They 
prefer XML declarations. So the question is 'How can we support them?'.
I don't think writing the database access layer in Groovy (or any other 
procedural programming language) helps them but maybe I'm wrong here.

Another point is the (often discussed) CocoonForms-database binding for 
this user group.

WDOT? Maybe we should collect some proposals and then poll our users?

-- 
Reinhard

Re: Modular database component

[Leon Widdershoven <qa...@dds.nl>]

Ugo Cei wrote:
> Leon Widdershoven wrote:
> 
>> I honestly do not care about the efficiency of my SQL. The database is
>> by far the fastest component. I do not think OJB can really optimize
>> a simple SELECT foo, bar from BLA; statement. There's just nothing to 
>> optimize!
> 
> 
> You can always optimize it away. That is, don't do the query at all if 
> you have cached the data. Since any serious ORM solution will give you 
> declarative and transparent support for caching, this alone is a big win 
> in some situations, IMHO.
> 
>     Ugo



I stand corrected.

Leon

Re: Modular database component

[Ugo Cei <u....@cbim.it>]

Leon Widdershoven wrote:
> I honestly do not care about the efficiency of my SQL. The database is
> by far the fastest component. I do not think OJB can really optimize
> a simple SELECT foo, bar from BLA; statement. There's just nothing to 
> optimize!

You can always optimize it away. That is, don't do the query at all if 
you have cached the data. Since any serious ORM solution will give you 
declarative and transparent support for caching, this alone is a big win 
in some situations, IMHO.

	Ugo

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

Leon Widdershoven dijo:
>
>> I will not be sure. Writing SQL code is always larger than using O/R
>> mapping tools and we already know many developers have problem with SQL.
>> They don't write optimal SQL queries. See slides 10-14:
>> http://cvs.apache.org/viewcvs.cgi/*checkout*/db-ojb/contrib/ojb-dataccess.pdf
>
> I honestly do not care about the efficiency of my SQL. The database is
> by far the fastest component. I do not think OJB can really optimize
> a simple SELECT foo, bar from BLA; statement. There's just nothing to
> optimize!

I think there is always place for optimization. ie: Take advantage of OJB
proxies, etc. I think optimization is good. But it is OT.

> I do think that when queries get a bit complicated, or when columns or
> tables are related, such tools are much preferred to SQL as it is just
> to easy to forget to do something. I'm not argueing that.

You need to see the "power" of beans before tell that. It is really very
easy. And if you worry for writing (I was too). There are tools as
eclipse.org that allow you to build beans very easy. There an option that
allow you to automatically generate getter and setters for beans. Groovy
also is a step forward in that:
http://groovy.codehaus.org/beans.html

> It's just the very simple stuff I'd like to keep simple. I have spent
> somehwat more than an hour now to try to get a mapping for my database
> auto-generated using the reverse-db tool of OJB. It just does not give
> me my table definitions. So now I search for another tool. All that
> takes time. Then comes a learning curve. And only then I can try to
> integrate it into my program into what amount to
> select fullname, username from auth where username='foo';
> I think simple things should not large tools to handle. It only introduces
> other bugs.

True, we miss the easy build wizards (as a friend of mine joked last
month). But this is the cost of using the lastest scream in technology,
right?

>> I think the SQL does not fit well into the OO world. That was told over
>> and over. The O/R mapping gives you the hability to work with tables as
>> Objects. As a sample, you can use JXPath and write something like:
>
> That's true. And javascript is not OO so the match is perfect:)
> Again, I agree O/R can be really usefull, but it can also be
> really overkill. If you start with a good working knowledge or O/R
> it's quite logical to use O/R.
> But if you're an expert in SQL, why throw that knowledge away?

I don't said, "forget SQL". O/R mapping is a higher level as programming
in C(++) while I know assembler. You have the advantage you really know
what is going behind the scenes of the C code. and this is a big plus and
helps to solve problems and write more efficient code.

>> objectA.objectB.usersList.user[1].name
>>
>> This is great to use this kind of Objects inside JXTG or in other
>> places.
>> Once you start using it, you will see there is not way back to plain
>> SQL.
>>
>
>>
>>>And who on earth needs a bridge or relational mapping for
>>>Select username, password from authentication where username = 'foo';?
>>>If you already have OJB up and running it is logical to use that, but
>>>to start learning OJB just for that???
>>
>>
>> I wonder if when SQL was a top technology, people had the same arguments
>> as you against SQL.
>
> Yes, of course. No-one likes to revalue his knowledge like Enron shares.
>
> And it was valid then, less valid now. Like SQL vs O/R nowadays. SQL has
> a lot of existing knowledge and tools. O/R is only starting. Books and
> tools about/for OJB are more difficult to find than for SQL. Which makes
> the technology harder to use - even if it is both better, less error
> prone and faster.

Yep. In fact this is the cost of using the lastest. I am aware of that. I
think being a early adopter is hard.

> And 15 years from now I will probably just as hard say that we should not
> go to a situation where the database uses both voice recognition
> andsemantic
> analysis on a recording or your voice to determine what you want from it,
> and give you the results spoken on your cellular phone:)

Nice glipse of the future. :-D

Best Regards,

Antonio Gallardo

Re: Modular database component

[Leon Widdershoven <qa...@dds.nl>]

> I will not be sure. Writing SQL code is always larger than using O/R
> mapping tools and we already know many developers have problem with SQL.
> They don't write optimal SQL queries. See slides 10-14:
> http://cvs.apache.org/viewcvs.cgi/*checkout*/db-ojb/contrib/ojb-dataccess.pdf

I honestly do not care about the efficiency of my SQL. The database is
by far the fastest component. I do not think OJB can really optimize
a simple SELECT foo, bar from BLA; statement. There's just nothing to optimize!

I do think that when queries get a bit complicated, or when columns or
tables are related, such tools are much preferred to SQL as it is just
to easy to forget to do something. I'm not argueing that.

It's just the very simple stuff I'd like to keep simple. I have spent
somehwat more than an hour now to try to get a mapping for my database
auto-generated using the reverse-db tool of OJB. It just does not give
me my table definitions. So now I search for another tool. All that
takes time. Then comes a learning curve. And only then I can try to
integrate it into my program into what amount to
select fullname, username from auth where username='foo';
I think simple things should not large tools to handle. It only introduces
other bugs.


> I think the SQL does not fit well into the OO world. That was told over
> and over. The O/R mapping gives you the hability to work with tables as
> Objects. As a sample, you can use JXPath and write something like:

That's true. And javascript is not OO so the match is perfect:)
Again, I agree O/R can be really usefull, but it can also be
really overkill. If you start with a good working knowledge or O/R
it's quite logical to use O/R.
But if you're an expert in SQL, why throw that knowledge away?

> objectA.objectB.usersList.user[1].name
> 
> This is great to use this kind of Objects inside JXTG or in other places.
> Once you start using it, you will see there is not way back to plain SQL.
> 

> 
>>And who on earth needs a bridge or relational mapping for
>>Select username, password from authentication where username = 'foo';?
>>If you already have OJB up and running it is logical to use that, but
>>to start learning OJB just for that???
> 
> 
> I wonder if when SQL was a top technology, people had the same arguments
> as you against SQL.

Yes, of course. No-one likes to revalue his knowledge like Enron shares.

And it was valid then, less valid now. Like SQL vs O/R nowadays. SQL has
a lot of existing knowledge and tools. O/R is only starting. Books and
tools about/for OJB are more difficult to find than for SQL. Which makes
the technology harder to use - even if it is both better, less error
prone and faster.

And 15 years from now I will probably just as hard say that we should not
go to a situation where the database uses both voice recognition andsemantic 
analysis on a recording or your voice to determine what you want from it,
and give you the results spoken on your cellular phone:)

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

>> 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:
>
> As a user: Of course you can. The question is whether you'd want to. Using
> OJB seems to demand that you set up descriptions of the tables, then
> create appropriate classes etc.

No see a problem here. We already have automation tools for that:
http://druid.sf.net/
(BTW, I want to share with you, that the a new proposal for a form
generator in Druid was aproved! The idea is to make it able to generate
for Woody). Well there is no line of code, but we already discused inside
our company about that and while the task is no simple is posible. The big
picture about this enhancement is:

User:
1-Define database (tables, fields, etc.)
2-Define forms (tables involved, fields, properties)

Then Druid generates for you:

1-Database SQL script builder (done)
2-Java Beans (done)
3-OJB (Hibernate) O/R map (needs improvements, but it works).
4-A basic woody definition.xml, binding.xml and templates.xml? for forms.

Of course this idea is in a very early development and is not our main
task, but is some people want to join the effort I invite them to
subscribe on the druid devel mail list.

> For a user, most of whom know a bit about SQL, or can read about it in the
> thousands of introductory level books, SQL is much easier, not to say more
> standard.

I will not be sure. Writing SQL code is always larger than using O/R
mapping tools and we already know many developers have problem with SQL.
They don't write optimal SQL queries. See slides 10-14:
http://cvs.apache.org/viewcvs.cgi/*checkout*/db-ojb/contrib/ojb-dataccess.pdf

I think the SQL does not fit well into the OO world. That was told over
and over. The O/R mapping gives you the hability to work with tables as
Objects. As a sample, you can use JXPath and write something like:

objectA.objectB.usersList.user[1].name

This is great to use this kind of Objects inside JXTG or in other places.
Once you start using it, you will see there is not way back to plain SQL.

> Furthermore, creating a query based on form input is just the
> concatenation of Strings.

> How much more easy can it get? As an added bonus, you can
> just log the queries in the developer phase and cut-and-paste them in
> the command line database tool to see why they would not work. If you
> use an added layer that power would either be lost or more difficult
> accessible.

See above...

> I fully see that OJB is more beatifull. But not all people who wish
> to write a simple flowscript app wish to start learning two major
> technologies at once; they would fall back on a familiar technology
> where possible to decrease the chance of failure.

Partially agree, but just because someone is not able to follow the best
practices this means we will drop them.

> I think more of providing an easy migration path from CRUD to OJB,
> using a MigrateFromCRUDToOJB Wiki page in which a simple CRUD flowscript
> is moved to the OJB framework, and a sketch of a situation where OJB
> is clearly easier to use that any other way.

Good idea, but this is a documentation issue. I never used the CRUD
flowscript. I even today never saw at the code inside the petstore sample.
I cannot comment about it.

> I think that, if you are familiar with OJB it is hard to see that things
> like hibernate and OJB seem daunting;

:-D Yes yo are right.

> even the name promisses sleepless nights.

The contrary is true. you will be able to sleep more, because you will
make more in lees time.

> And who on earth needs a bridge or relational mapping for
> Select username, password from authentication where username = 'foo';?
> If you already have OJB up and running it is logical to use that, but
> to start learning OJB just for that???

I wonder if when SQL was a top technology, people had the same arguments
as you against SQL.

As I pointed before, the "time" is a good teacher and it will tell us who
was right (Note, I am not assuming I am right). I believe we are still
trying some paths and some good practices. In that way, we cannot discard
nothing now. It is too early.

Best Regards,

Antonio Gallardo.

Re: Modular database component

[Leon Widdershoven <qa...@dds.nl>]

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:

As a user: Of course you can. The question is whether you'd want to. Using
OJB seems to demand that you set up descriptions of the tables, then
create appropriate classes etc.

For a user, most of whom know a bit about SQL, or can read about it in the
thousands of introductory level books, SQL is much easier, not to say more
standard.

Furthermore, creating a query based on form input is just the concatenation
of Strings. How much more easy can it get? As an added bonus, you can
just log the queries in the developer phase and cut-and-paste them in
the command line database tool to see why they would not work. If you
use an added layer that power would either be lost or more difficult
accessible.

I fully see that OJB is more beatifull. But not all people who wish
to write a simple flowscript app wish to start learning two major
technologies at once; they would fall back on a familiar technology
where possible to decrease the chance of failure.

I think more of providing an easy migration path from CRUD to OJB,
using a MigrateFromCRUDToOJB Wiki page in which a simple CRUD flowscript
is moved to the OJB framework, and a sketch of a situation where OJB
is clearly easier to use that any other way.

I think that, if you are familiar with OJB it is hard to see that things
like hibernate and OJB seem daunting; even the name promisses sleepless
nights. And who on earth needs a bridge or relational mapping for
Select username, password from authentication where username = 'foo';?
If you already have OJB up and running it is logical to use that, but
to start learning OJB just for that???

Leon

Re: Modular database component

[Daniel Fagerstrom <da...@nada.kth.se>]

Christopher Oliver wrote:

> Reinhard Poetz wrote:
>
> <snip>
>
>> 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.
>
>
> Just wondering, is there any real difference between having say a 
> <for-each-row query="select whatever from whatever"> macro in JXTG and 
> SQL transformer? In fact, wouldn't JXTG be more useful for publishing 
> (since you can perform conditional branching and additional variable 
> substitution) than SQL Transformer?

In many cases JXTG would be more usefull.

> Or, if not then perhaps SQL transformer itself should be eliminated. 
> At any rate, shouldn't it be a generator rather than a transformer? 

We quite often generate SQL queries from configuration files written in 
XML, and in such cases XML->XSLT->SQLTransformer->..., becomes a quite 
convinient way to do things. In earlier discussions about scrapping the 
SQLTransformer it seemed like this is a fairly common use pattern. So I 
would be strongly against not having some kind of SQL transformer in 
Cocoon, I'm open for improvements of the SQL transformer though.

/Daniel

Re: Modular database component

[Geoff Howard <co...@leverageweb.com>]

Christopher Oliver wrote:
> Reinhard Poetz wrote:
> 
> <snip>
> 
>> 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.
> 
> 
> Just wondering, is there any real difference between having say a 
> <for-each-row query="select whatever from whatever"> macro in JXTG and 
> SQL transformer? In fact, wouldn't JXTG be more useful for publishing 
> (since you can perform conditional branching and additional variable 
> substitution) than SQL Transformer? Or, if not then perhaps SQL 
> transformer itself should be eliminated. At any rate, shouldn't it be a 
> generator rather than a transformer?

In my personal opinion, we absolutely must have both a SQL Transformer and SQL 
Generator with basic scripting (be it JXTG, ESQL, USQL, Groovy, whatever) which 
is the recommended method in situation 2 above and others like it.

We have PHP, ColdFusion, ASP developers coming over to Cocoon because they've 
heard it's the greatest thing since sliced bread and adding O/R tools to the 
list of things they have to learn just to produce their first page displaying 
data from a database would send them running more than we already do.  There is 
a huge LAMP (linux, apache, MySQL, PHP) world out there and convincing them to 
become LAMCXmlXslSitemapMVCContinuationsFOMOJBJavaAvalonExcaliburSoCGoF people 
in one step is completely unrealistic.

I also think and have thought for some time that repackaging the ModDBActions as 
generalized components accessible from flow would be a great step forward for 
these types of users, and for anyone with relatively simple needs.  We need this 
  to keep people with script template backgrounds from doing data manipulation 
in the view layer (generator or transformer).  The only way to avoid that now is 
to point them back to actions or complicate the issue with OJB.  It may be that 
a scriptable component rather than the declarative moddb approach would be a 
better starting point for people - all the better.

Geoff

Re: Modular database component

[Reinhard Poetz <re...@apache.org>]

Christopher Oliver wrote:

> Reinhard Poetz wrote:
>
> <snip>
>
>> 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.
>
>
> Just wondering, is there any real difference between having say a 
> <for-each-row query="select whatever from whatever"> macro in JXTG and 
> SQL transformer? In fact, wouldn't JXTG be more useful for publishing 
> (since you can perform conditional branching and additional variable 
> substitution) than SQL Transformer? Or, if not then perhaps SQL 
> transformer itself should be eliminated. At any rate, shouldn't it be 
> a generator rather than a transformer?


I think the question is what you need it for: I believe that people 
writing *applications* using Cocoon shouldn't have to write SQL 
statements in their code. There are easier, and *more maintainable* 
solutions (O/R-mapper). If people use Cocoon for *publishing*, I think 
the situation is different and your proposal makes perfect sense.

It will be very interesting in the next months with all those efforts to 
generate XML (Groovy, Tempo, ...).

                                   - o -

Pls, don't get me wrong. I don't want to prevent anybody from developing 
any new way to generate XML in Cocoon. I _only_ want to find a clear 
statement within the Cocoon community which is the *recommended* way 
doing it and *why* we think so because at the moment we have to many 
options accessing DBs and generating XML without clear statements.

-- 
Reinhard

Re: Modular database component

[Christopher Oliver <re...@verizon.net>]

Reinhard Poetz wrote:

<snip>

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

Just wondering, is there any real difference between having say a 
<for-each-row query="select whatever from whatever"> macro in JXTG and 
SQL transformer? In fact, wouldn't JXTG be more useful for publishing 
(since you can perform conditional branching and additional variable 
substitution) than SQL Transformer? Or, if not then perhaps SQL 
transformer itself should be eliminated. At any rate, shouldn't it be a 
generator rather than a transformer?

Chris

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

Reinhard Poetz dijo:
> So Groovy becomes yet another alternative for database-based publishing,
> doesn't it?

Yep.

> Would you recommend it to create web *applications*?

It is just a RT. I don't write a line of code in thatway . But it is in my
long TODO from now. :-D

Best Regards,

Antonio Gallardo

Re: Modular database component

[Reinhard Poetz <re...@apache.org>]

Antonio Gallardo wrote:

>Reinhard Poetz dijo:
>
>  
>
>>After reading this one question remains: What is the reason why are
>>*you* interested in Groovy and its SQL support? Which problem do you
>>want to solve which can't be solved with OJB?
>>    
>>
>
>Groovy can help people that don't want to get involved with O/R mapping
>tools. They can write very easier SQL code in Groovy than in XSP or
>SQLTransformer.
>  
>

So Groovy becomes yet another alternative for database-based publishing, 
doesn't it?
Would you recommend it to create web *applications*?

-- 
Reinhard

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

Reinhard Poetz dijo:

> After reading this one question remains: What is the reason why are
> *you* interested in Groovy and its SQL support? Which problem do you
> want to solve which can't be solved with OJB?

Groovy can help people that don't want to get involved with O/R mapping
tools. They can write very easier SQL code in Groovy than in XSP or
SQLTransformer.

And
<RT>
Write Groovy code for DAO using OJB. And take some advantage of Groovy XML
support.
</RT>

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

+1. See also above.

Best Regards,

Antonio Gallardo

Re: Modular database component

[Reinhard Poetz <re...@apache.org>]

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

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

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

Re: Modular database component

[Leon Widdershoven <qa...@dds.nl>]

Joerg Heinicke wrote:

> On 20.04.2004 07:49, Reinhard Poetz wrote:
>
>>>> 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.
>>
>
> From Antonio's comment I guess he just misread your comment. To 
> restate it: Reinhard does not want flow scripts calling DB.
>
>> 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!!!
>
>
> Same here. DB should not be called from flow script - neither 
> JavaScript nor Groovy nor XYZ. The thing is about page flow.
>
>>>> 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!
>
>
> Same here again. I wonder why templating languages shall be featured 
> up with db access.
>
>> 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.
>
>
> +1 (to avoid writing "same here" again :) )
>
> Joerg


For beginning cocoon/flowscript users one should, if not providing 
direct SQL access, provide a well documented and above all
for simple scenarions EASY way. Setting up and integrating either OJB 
and Hibernate do nut fullfill that condition yet.

I also think that requiring Java classes to be pre-generated (and then 
included in the classpath) for even the simplest queries is not
a problem for developers and advanced users, but is to much to ask for a 
user just starting who just wants to display his
address data or something alike. I think it is unclean, classes should 
be put in the application. A way to describe/map the database
using XML (as done by Hibernate and OJB both) should suffice - the rest 
should be done on the fly like with  xsp. That is by far
the easiest. For advanced uses where those classes are extended one 
could think of precompiled classes.

The way to gain acceptance for a superior framework is to make it just 
as easy as using plain SQL IMHO. Nothing beats the
simplicity at present of pure SQL access - for simple apps. Let's not 
make any new framework/component difficult to start
with. Power should be available on demand, complexity postponed (Yes - 
someone told me it's an on demand world nowadays:)

Leon

Re: Modular database component

[Joerg Heinicke <jo...@gmx.de>]

On 20.04.2004 07:49, Reinhard Poetz wrote:

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

 From Antonio's comment I guess he just misread your comment. To restate 
it: Reinhard does not want flow scripts calling DB.

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

Same here. DB should not be called from flow script - neither JavaScript 
nor Groovy nor XYZ. The thing is about page flow.

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

Same here again. I wonder why templating languages shall be featured up 
with db access.

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

+1 (to avoid writing "same here" again :) )

Joerg

Re: Modular database component

[Reinhard Poetz <re...@apache.org>]

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.

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

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

Guido Casper dijo:
> That's interesting. Would you care to explain to me what the difference
> between a DB transaction and an object transaction is?

In short:
Any O/R map tool has the DB model loaded in a set of diferent Java
Objects. That way, we have to worlds that need to be synchronized: The DB
world and the Object world. See:

http://db.apache.org/ojb/faq.html#How%20is%20OJB%20related%20to%20ODMG%20and%20JDO?

Some API does not support the Object transaction level. This is the case
of PersistenceBroker in OJB.

Best Regards,

Antonio Gallardo

Re: Modular database component

[Joerg Heinicke <jo...@gmx.de>]

On 20.04.2004 20:39, Guido Casper wrote:

> That's interesting. Would you care to explain to me what the difference 
> between a DB transaction and an object transaction is?

DB transactions are the normally known transactions and about atomicity 
of multiple sql statements put together. Object level transactions 
ensure atomicity of all changes done on an object and possible dependencies:

"The ODMG API uses object-level transactions, compared to the 
PersistenceBroker dat abase-level transactions. An ODMG  Transaction 
instance contains all of the changes made to the object model within the 
context of that transaction, and will not commit them to the database 
until the ODMG  Transaction   is committed. At that point it will use a 
database transaction to ensure atomicity of its changes." [1]

Joerg

[1] 
http://www.google.de/search?q=cache:BIZvd92HVDkJ:db.apache.org/ojb/odmg-tutorial.html+site:db.apache.org+%22object+level%22+transaction&hl=de&ie=UTF-8

Re: Modular database component

[Guido Casper <gc...@s-und-n.de>]

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.

That's interesting. Would you care to explain to me what the difference 
between a DB transaction and an object transaction is?

<snip/>

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

> 
> 
> I will prefer OJB people to make what they do the best.

which is an O/R-mapper for which you need an object model, which you 
might not have (and maybe don't want to have).

BTW do you have an idea how OJB might work with Dynabeans (or XMLBeans)? 
(just thinking out loud again)

Guido

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

-- 
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5    mailto:gcasper@s-und-n.de
D-33100 Paderborn   http://www.s-und-n.de
-------------------------------------------------

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

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

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

Guido Casper dijo:
>> Yep. We can get OJB components outside Avalon. We are doing this too
>> now.
>> The remain question is to delete the OJB block or let it live to show
>> users how they can use it.
>
> +1 to let it live as a lightweight block. If O/R-mapping is our
> recommendation for enterprise level requirements, we should at least
> have some demonstrating samples (maybe these shouldn't be JDO-based? I
> didn't know that OJB has that many options). Over time it might evolve
> into something more "flowscript-supportive".

Yep. OJB has other APIs. There are 4 APIS now.

Currently, the JDO support is broken or partially broken and does not work
in OJB. I think I setted the entry-level to high with JDO. All in all JDO
is not dificult, but when you are newbie and the OJB support is broken you
cannot help yourself and the technology seems to be too dificult.

This soon will change because OJB committers are working now in
development of a full implementation of JDO in OJB. I hope they will
finish it soon.

But now, we can use PB, OTM or ODMG to make the work done.

Best Regards,

Antonio Gallardo

Re: Modular database component

[Guido Casper <gc...@s-und-n.de>]

Antonio Gallardo wrote:

> Tony Collen dijo:
> 
>>Hmm, how hard would it be to come up with some sort of Avalon component
>>that wraps OJB's PersistenceManager?  Or would we not even have to use
>>it as an Avalon component if we can just directly get a
>>PersistenceManager instance?
>>
>>I would wager that if we had easy access to the PersistenceManager (or
>>other similar things) in Flow, that could easily cover 80% of the use
>>cases.
> 
> 
> Yep. We can get OJB components outside Avalon. We are doing this too now.
> The remain question is to delete the OJB block or let it live to show
> users how they can use it.

+1 to let it live as a lightweight block. If O/R-mapping is our 
recommendation for enterprise level requirements, we should at least 
have some demonstrating samples (maybe these shouldn't be JDO-based? I 
didn't know that OJB has that many options). Over time it might evolve 
into something more "flowscript-supportive".

Guido

-- 
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5    mailto:gcasper@s-und-n.de
D-33100 Paderborn   http://www.s-und-n.de
-------------------------------------------------

Re: Modular database component

[Antonio Gallardo <ag...@agssa.net>]

Tony Collen dijo:
> Hmm, how hard would it be to come up with some sort of Avalon component
> that wraps OJB's PersistenceManager?  Or would we not even have to use
> it as an Avalon component if we can just directly get a
> PersistenceManager instance?
>
> I would wager that if we had easy access to the PersistenceManager (or
> other similar things) in Flow, that could easily cover 80% of the use
> cases.

Yep. We can get OJB components outside Avalon. We are doing this too now.
The remain question is to delete the OJB block or let it live to show
users how they can use it.

Best Regards,

Antonio Gallardo.

Re: Modular database component

[Tony Collen <co...@umn.edu>]

Antonio Gallardo wrote:
> Reinhard Poetz dijo:
> 
> 
>>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 ...


Hmm, how hard would it be to come up with some sort of Avalon component 
that wraps OJB's PersistenceManager?  Or would we not even have to use 
it as an Avalon component if we can just directly get a 
PersistenceManager instance?

I would wager that if we had easy access to the PersistenceManager (or 
other similar things) in Flow, that could easily cover 80% of the use 
cases.

Just thinking out loud,

Tony

Re: Modular database component

[Reinhard Poetz <re...@apache.org>]

Bertrand Delacretaz wrote:

> Le 19 avr. 04, à 11:08, Reinhard Poetz a écrit :
>
>> ...I have to think more about the API of this component but first I 
>> want to talk more about the background of my idea. I had several 
>> discussions with Alex Schatten and we came to the conclusion that, 
>> generally spoken, there are two database usage scenarios:
>>
>> 1. Enterprise Level
>
>
> Where you need java code and/or O/R mapping tools, no question about 
> this.
>
>> 2. Simple database applications
>>    Usually very small projects where you need only a few 
>> 'interactive' pages.
>>
>> If you are familiar with O/R-mapping tools I always recommend them, 
>> also in scenario two...
>
>
> Ok, but our users lists shows clearly that many people are doing stuff 
> directly in SQL, for various reasons, including the welcome 
> "transparency" of SQL when doing simple things.
>
> And I'd add a third category
>
> 3. Read-only database publishing or mining applications
>
> Where you do no transactions, only queries, and where O/R mapping does 
> not bring much to the SQL -> XML -> whatever chain.


See below

>
>> ...IMO there are users who don't want to write programmes at all. 
>> They prefer XML declarations. So the question is 'How can we support 
>> them?'.
>
>
> Don't you think many of these users would prefer writing simple 
> scripts rather than XML declarations?
>
> But I'm thinking more about providing an alternative to the ESQL / 
> SQLTransformer stuff, maybe you're seeing things from a different 
> point of view?


I'm talking if really simple applications like a registration form, a 
simple page filling one table with data, or something like that. As soon 
as you need more I recommend using O/R-mapping tools because they are 
easier to use as many people think!

>
>> ...WDOT? Maybe we should collect some proposals and then poll our users?
>
>
> Hmmm...it might be better to come up with examples or use-cases of 
> what you think a ModularDatabaseComponent could be so that people can 
> judge on code. Otherwise I'm afraid a pool could lead to much talk 
> without a concrete outcome.


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

Following this I don't see the need for

 a. calling DB from within Flowscripts
 b. code CRUD in templates (Groovy, JXTemplate, ...) and XSP

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.


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", {});
}


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

Comments?

> Unfortunately I currently lack the time to work seriously on the 
> Groovy/DB stuff. I'll try to not talk too much about it until 
> something usable is here ;-)
>
> -Bertrand

-- 
Reinhard

Re: Modular database component

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Le 19 avr. 04, à 11:08, Reinhard Poetz a écrit :
> ...I have to think more about the API of this component but first I 
> want to talk more about the background of my idea. I had several 
> discussions with Alex Schatten and we came to the conclusion that, 
> generally spoken, there are two database usage scenarios:
>
> 1. Enterprise Level

Where you need java code and/or O/R mapping tools, no question about 
this.

> 2. Simple database applications
>    Usually very small projects where you need only a few 'interactive' 
> pages.
>
> If you are familiar with O/R-mapping tools I always recommend them, 
> also in scenario two...

Ok, but our users lists shows clearly that many people are doing stuff 
directly in SQL, for various reasons, including the welcome 
"transparency" of SQL when doing simple things.

And I'd add a third category

3. Read-only database publishing or mining applications

Where you do no transactions, only queries, and where O/R mapping does 
not bring much to the SQL -> XML -> whatever chain.

> ...IMO there are users who don't want to write programmes at all. They 
> prefer XML declarations. So the question is 'How can we support 
> them?'.

Don't you think many of these users would prefer writing simple scripts 
rather than XML declarations?

But I'm thinking more about providing an alternative to the ESQL / 
SQLTransformer stuff, maybe you're seeing things from a different point 
of view?

> ...WDOT? Maybe we should collect some proposals and then poll our 
> users?

Hmmm...it might be better to come up with examples or use-cases of what 
you think a ModularDatabaseComponent could be so that people can judge 
on code. Otherwise I'm afraid a pool could lead to much talk without a 
concrete outcome.

Unfortunately I currently lack the time to work seriously on the 
Groovy/DB stuff. I'll try to not talk too much about it until something 
usable is here ;-)

-Bertrand

Re: Modular database component

[Joerg Heinicke <jo...@gmx.de>]

On 19.04.2004 11:08, Reinhard Poetz wrote:

> If you are familiar with O/R-mapping tools I always recommend them, also 
> in scenario two.
> 
> The question is, how do we deal with scenario two if the user is _not_ 
> familiar with e.g. OJB. I think O/R-mapping is rather straight forward 
> but IMO there are users who don't want to write programmes at all.

IMO learning mapping file XML dialects, O/R mapper configuration files 
and so on is to much stuff for the beginning. Let them start with pure 
SQL or poorly abstracted syntax. If that's ESQL, SQLTransformer, or 
Groovy is unimportant IMO. There only must be the possibility.

> They prefer XML declarations.

XML declarations? Probably I don't get the point.

> Another point is the (often discussed) CocoonForms-database binding for 
> this user group.

Binding forms directly to databases sounds weird. There are not many use 
cases IMO, maybe questionnaires for most simple inserts. Even reports do 
not show database data directly, do they?

Joerg