You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2003/03/01 00:35:14 UTC
XMLForms and O/R bridge. The Road Ahead.....
Hi!
After seeing how Christian and Ugo greatly done the relation between
XMLForms and Flow.
A Bean is the model of the MVC, XMLForm the View and Flow the controller.
A short of this can be B-XMLF-F. :-)
Now still stay in the air the question of how to handle the "down" side of
the persistent Model (the Database Connection - this is my point of
view).....
Currently, we saw some concurrents paths:
Hibernate [1]
OJB [2]
Torque [3]
and some others.... (Please feel free to fill this list).
My question for the gurus of this stuff is: Wich path is the correct way
in this effort?
Best Regards,
Antonio Gallardo.
[1] Hibernate Home Page - http://hibernate.bluemars.net/
[2] OJB Home Page - http://db.apache.org/ojb/
[3] Torque Home Page - http://db.apache.org/torque/
Re: XMLForms and O/R bridge. The Road Ahead.....
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Saturday, March 1, 2003, at 10:23 AM, Per-Olof Norén wrote:
> Sorry for the really sloppy snip, Stefano and Antonio.
> Didnt mean to distort your orginal messages.
>
We'll forgive you
......
as long as you write up some stuff on using Apache OJB with XForms +
Flow ;)
Sorry, only joking ;)
regards Jeremy
Re: XMLForms and O/R bridge. The Road Ahead.....
Posted by Per-Olof Norén <pe...@alma.nu>.
Sorry for the really sloppy snip, Stefano and Antonio.
Didn´t mean to distort your orginal messages.
regards,
Per-Olof Norén
Cocoon flow + O/R samples [was Re: XMLForms and O/R bridge. The
Road Ahead.....]
Posted by Per-Olof Norén <pe...@alma.nu>.
Hi again, sorry for the delay.
<massive snip/>
>>
>>
>> Having used cocoon and OJB for no less than four (4) of our projects
>> I can only say that the combination of flow + OJB really makes life
>> easier. We´re using OJB by reversing the db into an OJB-mapping file
>> for which we generate beans that in turn is used from the flow java
>> script.
>
>
> I think it could be an incredibly useful contribution if you could
> write a few samples that show how to do it. A tutorial will be even
> better, but knowing coders, sometimes I sample is even better.
We´re currently in the process of making a final delivery to our
customers, and time is a little limited
Because of this I think we could have sample available in a week or two
at the earliest. Unfortunatly...bare with us :-)
>> btw:
>> During this process we´ve come up with some enhancements to the
>> jpath.xsl logicsheet to allow nested <jpath:for-each/>.
>> We´ll start discussing how to get you guys to commit real soon :-)
>
>
> Let's see: you submit your samples along with that patch, and I'll
> commit it right away, how's that as a deal? :-)
Deal :-)
<snip/>
> There is no way to estimate how complex a web application is or how
> much time is going to take to write it, or, more important, how much
> it can be reused in other projects that partially share the same
> concerns.
A good example of this is our "Datepicker" function and complementing
xsp. When this function returns, the user has clicked interacted and
selected a date. If one were to go a little further and actually
declare a JavaScript object for it, it would be possible formalize its
usage further. This isn´t interacting with the db and could easily be
packaged into a small sample app.
Regards,
Per-Olof Norén
[WOT] how to improve your ant build speed
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> Jason Foster wrote:
>
>>> Sure the flowscript layer can (and will, I'm sure) be abused, but as
>>> much as ant build files, or sitemaps can reach a point where the mess
>>> and performance drags you down and refactoring is needed.
>>
>>
>> Since you did bring it up... ;)
>>
>> Could you offer some tips on "how to refactor an ant build script for
>> fun and profit in order to achieve order-of-magnitude improvements"?
>> I'm curious about the mental model you were using during the
>> refactoring, as the details can be gleaned from the build.xml
>
> It was a quite easy trick, to tell you the truth...
Whatever! here's the true story.
> Stefano came and visit us in January, I fiddled with his laptop screen
> and broke it (bye bye laptop screen)...
The screen connection of my VAIO was already damaged. But it's true that
was Pier that finally broke it. bye bye laptop screen holder... but the
screen still works, the laptop just is not portable anymore.
> While he was trying to fix the screen he spilled some milk on the now
> disassembled keyboard (without noticing that the glass I provided was
> soaked in oil, and therefore very slippery).
That's BS: I got the glass myself and you were at work!
> Trying to clean the keyboard, he severed some of the contacts in the
> membrane (whops, was there a razor-blade in that Q-Tip I gave you, Stef?
> How unfortunate...)
You ain't gave me nothing, bro. I used TP around a screwdriver and I
didn't know those stupid membranes were sooooooooo fragile. But now I know.
> Now, I recommend him to buy a new PowerBook-G4... To do so Stefano needs
> to raise some money, and to do so, he can simply build a site using
> Cocoon...
Well, the deal was a little different: I come back home, my father needs
better email, I say "get a provider provider", he says "why don't you do
it", I think "doh!" and say "sure" thinking "no way". Than, frustrated
by tons of phone calls about how shitty the whole internet is and how
they can't do this and that (NOTE: my father is John Deere dealer. They
sell tractors and combines. )
> So, Stefano signs the contract and orders the new PowerBook...
Stefano doesn't sign anything and starts working on the site, having his
friend Pier hosting email and web on his machines in london (thank!) and
we start talking about how to improve things that we don't like.
So, here comes jetty, the mod_proxy tutorial and I finally sit down and
start.
> Ideally (how convenient), the Apple dealer is a friend of mine, and the
> leptop shipment is misteriously delayed... OF MONTHS, I might want to
> add...
Note that I landed in Italy a month ago. Take notes: Pier's sense of
time is *screwed*!!! if he says "i'll be there by noon", expect him
between 2/3PM. One time he even pretended the cops got him.
> Unfortunately Stefano has to build the site on his old home PC (_SLOW_
> as hell, you wouldn't believe it)...
My laptop is teared apart but still operational (well, more or less). My
desktop was given to my father since half of his problems were due to a
Pentium 120 with 32 mb of RAM running Win95 with IE6.0, no wonder why he
was annoyed!
> After one week of "build run" he
> gets frustrated and rewrites the entire build system...
After *one* run of 'build run', after seeing the "init" task passing on
my screen for the *fifth* time, I said "that's it" and rewrote it.
> So, the whole story is, if you want someone to do something concerning
> performance, first make sure that you are going to destroy all his
> computers but one (the slow 6-years-old one with no RAM), you get him
> annoyed by making him do something CPU intensive for a week, and after
> that he'll figure out that probably it's time to rewrite stuff! :-)
>
> Eeeeeeeeaaaaaaaaasyyyyyyyyyyy....
Pier is right in one thing: you should be building software on slower
machines, not on those massive Ghz-based dual CPU systems.
But enough is enough and I'll be getting my Powerbook G4 next week!! Of
somebody is going to get hurt (doesn't matter if I have to jump onto a
plane to do it, got it buddy? :)
- o -
All right, enough sunday morning stupidity.
The old build system had one serious problem: massive use of memory lead
to massive use of fork="true" on all calls to <javac> <ant> and
<javadoc>. Javac leaks memory, that's true, but not so much that we
can't handle a few runs with it.
The problem with forking <ant> calls was that ant had no way to know the
previous dependency graph, so had to re-execute all targets that were
already previously executed.
But in order to remove the fork="true" attributes from those tasks, I
needed to reduce memory consuption in the build.
Also, the dependency graph between targets was completely out of
control. Tasks were dependent on tasks without reason, maybe just to
make a directory. There was no coherent plan since it grew up from the
work of tens of people on two years.
Also, the block-build.xml generated file had a few tasks that were
useful only on *one* block, but where executed everytime! I still have
to figure out a way to solve that issue, but removing that improved
speed a lot.
Also, I removed all checks for libraries that were in blocks. I removed
all file copying. I placed all java files in a directory structure that
matched exactly the package name, so that ant can know not to recompile
something.
I did *massive* care about making sure that subsequent runs went smooth,
without requiring recompilation or repackaging.
I think there are still a few things to tweak to be faster, but it would
be a few seconds, not more.
Anyway, the build system was simply too complex and I restarted from
scratch and it worked. It'a painful job, expecially in a complex system
like Cocoon's, but it's worth it. Now I can do a 'cvs update' then
'build webapp' and takes no more than 60 seconds (less if I use jikes as
a compiler). And this is good enough for now.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: XMLForms and O/R bridge. The Road Ahead.....
Posted by Pier Fumagalli <pi...@betaversion.org>.
Jason Foster wrote:
>> Sure the flowscript layer can (and will, I'm sure) be abused, but as
>> much as ant build files, or sitemaps can reach a point where the mess
>> and performance drags you down and refactoring is needed.
>
> Since you did bring it up... ;)
>
> Could you offer some tips on "how to refactor an ant build script for
> fun and profit in order to achieve order-of-magnitude improvements"?
> I'm curious about the mental model you were using during the
> refactoring, as the details can be gleaned from the build.xml
It was a quite easy trick, to tell you the truth...
Stefano came and visit us in January, I fiddled with his laptop screen
and broke it (bye bye laptop screen)...
While he was trying to fix the screen he spilled some milk on the now
disassembled keyboard (without noticing that the glass I provided was
soaked in oil, and therefore very slippery).
Trying to clean the keyboard, he severed some of the contacts in the
membrane (whops, was there a razor-blade in that Q-Tip I gave you, Stef?
How unfortunate...)
Now, I recommend him to buy a new PowerBook-G4... To do so Stefano needs
to raise some money, and to do so, he can simply build a site using
Cocoon... So, Stefano signs the contract and orders the new PowerBook...
Ideally (how convenient), the Apple dealer is a friend of mine, and the
leptop shipment is misteriously delayed... OF MONTHS, I might want to add...
Unfortunately Stefano has to build the site on his old home PC (_SLOW_
as hell, you wouldn't believe it)... After one week of "build run" he
gets frustrated and rewrites the entire build system...
So, the whole story is, if you want someone to do something concerning
performance, first make sure that you are going to destroy all his
computers but one (the slow 6-years-old one with no RAM), you get him
annoyed by making him do something CPU intensive for a week, and after
that he'll figure out that probably it's time to rewrite stuff! :-)
Eeeeeeeeaaaaaaaaasyyyyyyyyyyy....
Pier
Re: XMLForms and O/R bridge. The Road Ahead.....
Posted by Jason Foster <re...@fastmail.fm>.
> Sure the flowscript layer can (and will, I'm sure) be abused, but as
> much as ant build files, or sitemaps can reach a point where the mess
> and performance drags you down and refactoring is needed.
Since you did bring it up... ;)
Could you offer some tips on "how to refactor an ant build script for
fun and profit in order to achieve order-of-magnitude improvements"?
I'm curious about the mental model you were using during the
refactoring, as the details can be gleaned from the build.xml
Jason Foster
Re: XMLForms and O/R bridge. The Road Ahead.....
Posted by Stefano Mazzocchi <st...@apache.org>.
Per-Olof Norén wrote:
> Stefano Mazzocchi wrote:
> First of I´d like to say that we decided not to used XMLForms in favor
> of pure flowscript, since we´re building large business applications.
> Despite the direction change we took, I really appriciate the XMLForms...
> <snip/>
>
>> I know Ugo likes hibernate but I suggested him to take a look at OBJ
>> and see if it could be usable for our needs (at least come up with a
>> few samples that use it to show). Maybe he can comment on this.
>
>
> Having used cocoon and OJB for no less than four (4) of our projects I
> can only say that the combination of flow + OJB really makes life
> easier. We´re using OJB by reversing the db into an OJB-mapping file for
> which we generate beans that in turn is used from the flow java script.
I think it could be an incredibly useful contribution if you could write
a few samples that show how to do it. A tutorial will be even better,
but knowing coders, sometimes I sample is even better.
> To do this we "tweaked" the reversedb scripts from OJB repo (this was
> OJB 0.94). By doin g this, we can change our datamodel once every five
> minutes if we want to, which makes OJB + cocoon based projects not only
> a very good RAD/prototyping tool, but also a very good way of building
> web applications.
> I´d recomend it to Ugo anyday.
Please, show us the code! I'm sure a lot of people are interested.
> btw:
> During this process we´ve come up with some enhancements to the
> jpath.xsl logicsheet to allow nested <jpath:for-each/>.
> We´ll start discussing how to get you guys to commit real soon :-)
Let's see: you submit your samples along with that patch, and I'll
commit it right away, how's that as a deal? :-)
> The power to "surf" the data model through xpath is just *so* powerful.
Yes, it makes perfect sense.
> We even prototype large parts of business logic in javascript and when
> customers decide and demands are clearer (since customers have seen in
> it in action) ,we move the business logic into its proper place in a
> java use case implementation class in a suitable package.
I believe that Cocoon will show how the power of weakly typed RAD-ness
can be turned into more solid (and strongly typed) solution in an
incremental way.
Sure the flowscript layer can (and will, I'm sure) be abused, but as
much as ant build files, or sitemaps can reach a point where the mess
and performance drags you down and refactoring is needed.
Anyway, what I really like about this approach is that the site of those
files that drive the process (build for ant, sitemap and flowscripts for
cocoon) really *measures* the complexity of the application.
Finding a meaningful metric for web application complexity (both
publishing-intensive and not) has been the holy grail in
accademic-oriented groups since the web started and nobody is closer
than Cocoon to provide a reasonable solution to that problem.
And if you ever had to patch a *-based web application written by
somebody else (substitue * with any between JSP|ASP|PHP|Perl) you know
what I mean: the number of files measures the number of states (not even
pages!), but has no information on the number of state transitions, nor
information on the number of output channels (if more than one). It's
normally faster and less expensive to throw it away and rewrite it. And,
if not, there is no way to tell!!!
There is no way to estimate how complex a web application is or how much
time is going to take to write it, or, more important, how much it can
be reused in other projects that partially share the same concerns.
Cocoon 2.0 has already changed all this for publishing-intensive web usages.
I expect Cocoon 2.1 to take the same approach onto the entire range of
web needs.
> Anyways, with all the things going on right now in the cocoon project,
> I´m certain 2.1 will be the release of the century!
Well, there are 97 years left in this century, I think we'll have enough
time to improve something :)
> Keep up the good work and spirit!
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: XMLForms and O/R bridge. The Road Ahead.....
Posted by Per-Olof Norén <pe...@alma.nu>.
Stefano Mazzocchi wrote:
First of I´d like to say that we decided not to used XMLForms in favor
of pure flowscript, since we´re building large business applications.
Despite the direction change we took, I really appriciate the XMLForms...
<snip/>
> I know Ugo likes hibernate but I suggested him to take a look at OBJ
> and see if it could be usable for our needs (at least come up with a
> few samples that use it to show). Maybe he can comment on this.
Having used cocoon and OJB for no less than four (4) of our projects I
can only say that the combination of flow + OJB really makes life
easier. We´re using OJB by reversing the db into an OJB-mapping file for
which we generate beans that in turn is used from the flow java script.
To do this we "tweaked" the reversedb scripts from OJB repo (this was
OJB 0.94). By doin g this, we can change our datamodel once every five
minutes if we want to, which makes OJB + cocoon based projects not only
a very good RAD/prototyping tool, but also a very good way of building
web applications.
I´d recomend it to Ugo anyday.
btw:
During this process we´ve come up with some enhancements to the
jpath.xsl logicsheet to allow nested <jpath:for-each/>.
We´ll start discussing how to get you guys to commit real soon :-)
The power to "surf" the data model through xpath is just *so* powerful.
We even prototype large parts of business logic in javascript and when
customers decide and demands are clearer (since customers have seen in
it in action) ,we move the business logic into its proper place in a
java use case implementation class in a suitable package.
Anyways, with all the things going on right now in the cocoon project,
I´m certain 2.1 will be the release of the century!
Keep up the good work and spirit!
regards,
Per-Olof Norén
Curalia AB
Re: XMLForms and O/R bridge. The Road Ahead.....
Posted by Stefano Mazzocchi <st...@apache.org>.
Antonio Gallardo wrote:
> Hi!
>
> After seeing how Christian and Ugo greatly done the relation between
> XMLForms and Flow.
>
> A Bean is the model of the MVC, XMLForm the View and Flow the controller.
> A short of this can be B-XMLF-F. :-)
>
> Now still stay in the air the question of how to handle the "down" side of
> the persistent Model (the Database Connection - this is my point of
> view).....
>
> Currently, we saw some concurrents paths:
>
> Hibernate [1]
> OJB [2]
> Torque [3]
> and some others.... (Please feel free to fill this list).
>
> My question for the gurus of this stuff is: Wich path is the correct way
> in this effort?
Assuming you know I'm no guru of database technology at all, I have a
few things to say from a community dynamics point of view:
1) Hibernate is LGPL. This rules it out for ASF-wide policies. You can
use it yourself, but we can't ship it nor have mock classes for clean
compilation, nor include source files that import their classes.
The other two are ASF-stuff.
Jon Stevens and I talked about Torque vs. OJB. He used Torque for Scarab
and he's happy, but does a 'object -> schema' generation, which is
hardly the case in real production environments (normally you get a
database and you have to map objects to that, not the other way around).
Hibernate has a much better support for these things.
Also, He said that OBJ is a much more dynamic model, while Torque is
just a code generator. But I don't know OBJ enough to tell you what this
really means in real life.
I know Ugo likes hibernate but I suggested him to take a look at OBJ and
see if it could be usable for our needs (at least come up with a few
samples that use it to show). Maybe he can comment on this.
Another alternative is the use of the Castor JDO, even if many don't
like Castor.
but I have no first-hand experience with any object-relational tools so
I'll let somebody else do the real discussion.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------