Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4391D47B.2020406@apache.org>
Date: Sat, 03 Dec 2005 18:23:07 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 1.5 (Macintosh/20051025)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT][long] Cocoon 3.0: the necessary mutation
References: <43908B84.7070909@apache.org>
 <8b8d97d20512021358t5775d329v5c50c5caafe4d8b@mail.gmail.com>
In-Reply-To: <8b8d97d20512021358t5775d329v5c50c5caafe4d8b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Irv Salisbury wrote:
> I realize I am not a committer or anything, but hopefully that doesn't 
> prevent me from replying...

Sure. This the reason why development happens in public: everybody is 
welcome and can voice his opinion.

> We have built a number of large cocoon based applications over the 
> past 2.5 years.  Everything you said in here is great, and I would 
> love it if cocoon had it.  I won't even comment on what you have 
> written as I agreed with all of it.
>
> I would like to add a few more comments
>
> 1. CForms - Our recent app has about 175 CForms.  Each of the binding, 
> definition, and template files were cocoon: URLs.  For doing simple 
> forms, having to write 3 files was a real pain and very time 
> consuming.  So, we started building our own meta file that contained 
> enough information to generate all 3 files necessary on the fly.  I am 
> sure others have done so as well.  It seems like for the simple cases 
> (or even the medium cases) we should be able to get away with 1 or 
> even 2 files that should have to be written.  CForms is great, and 
> making this easier to work with would be great.

I wholeheartedly agree with you. CForms is powerful, but requires to 
write reformulations of a single model in too many places. Domain model 
(beans, xsd or sql schema), form, binding and to some extent template. 
This a place where Rails and Django shine by enforcing the DRY principle 
(Don't Repeat Yourself), even if we can consider they went too far in 
the opposite direction.

I also used the approaches you mention (have you seen def2binding.xsl in 
o.a.c.forms.resources?) and the recent SQL sample in CForms that uses 
direct mapping of resultsets to forms is targeting in that direction too.

> 2. Memory usage.  Now, maybe Stax helps with this, but I don't think 
> so.  With our latest app, which was pretty large, we had pipelines 
> with many many steps in them.  Often, these steps would be simple 
> things that just change 1 or 2 elements in the XSL stream.  When you 
> are building a large cocoon app, you often needs lots of data flowing 
> through the system.  Each step in the pipeline generates sax events 
> and memory garbage, even if you don't need it.  To get around this, we 
> wound up using XMLBeans and having Java objects "flowing" through the 
> system  that can be turned into XML on the fly.  When you have a large 
> cocoon app with lots of users, there is a lot more memory usage than 
> other frameworks.

Yup.

> 3. More integration with XMLBeans (or JAXB).  Going back and forth 
> from JavaFlow to XML has benefits.  (I agree with your earlier point 
> that we shouldn't have to start with pipelines).  XMLBeans (or JAXB) 
> makes this a snap.  It has the speed of SAX and the benefit that you 
> can go back and forth between XML and Java easily.  We made a lot of 
> use of this in our recent app.  It worked great.  Downside is that you 
> have to write an XML Schema for all XML interactions.  (Which is also 
> a good thing as it is then documented)  I realize this wouldn't help 
> the learning curve at all.

Interesting.

> 4. Java flow (or flowscript) as the ONLY pipeline language.  Now, this 
> may be too touchy, but if all requests entered into Javaflow or 
> Flowscript, and then this was used as the "orchestration" language, I 
> think that would be great.  Make it so you can easily aggregate 
> pipelines, do content based routing, etc.  Pipelines then can be 
> simpler and all logic is done in flowscript or Javaflow.  You should 
> be able to setup all your components in flow.  Having this in Java or 
> Javascript would make conditional processing much easier and removing 
> the pipeline (as sacred as it is) would help us only have 1 language.

This is an idea that went through my head while writing the RT: move 
away from the sitemap language and do everything with the pipeline API. 
Now the declarative nature of the sitemap (even if it's actually a 
programming language) makes it easy to have an overall view of how the 
XML processing works. But the sitemap can also be the worst thing in the 
world when many subpipelines and components with side effects are used!

> 5. Continuations.  More needs to be understood about these.  We found 
> in our app that we spent a lot of time debugging how and when these 
> are created, why they are created, and getting rid of them.  It seems 
> like for a simple Javaflow call, should we really create a 
> continuation?  If you don't ever do a sendPageAndWait, and simply use 
> it as processing, why bother with the continuation?  It is just 
> something else that creates memory usage and something we have to 
> worry about destroying.
>
> Cocoon is awesome and with AJAX and other XML technologies becoming 
> more popular, it is slated to be THE framework to choose.  I think you 
> are very correct in that it won't be the way it is currently written.

Yep. There are some good concepts in Cocoon, but they are buried so deep 
that people have hard times using them to their real power.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director