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 <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
