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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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.
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
On Apr 19, 2004, at 4:49 PM, Reinhard Poetz wrote:
leo leonid wrote:
Hi all,
just curious, did ever someone in cocoonland, except me, use the
SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is
from where Chris borrowed the Petstore sample, that he ported to
flow. And that was
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
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
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
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
Le 19 avr. 04, à 10:51, Antonio Gallardo a écrit :
...I will be glad to propose a
Groovy block that will use BSF more oriented to Groovy needs. Something
like precompiling support of classes, then if the source don't change
we
will be able to run the class as a generator (as XSP do now)
Of
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,
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
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,
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
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
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
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
30 matches
Mail list logo
