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