I started to write a really long response but though better of it. The
bottom line here, is that what you are doing is not "wrong". It is probably
exactly how I would implement your site. However, pardon me for saying so,
your site is fairly simple. As the system grows larger you will find that
your flowscript is turning into a full-blown application, which is exactly
what I feel it shouldn't be.
<snipped>Rationale for "Flowscript considered harmful" (more or less)</snipped>
Ralph,
while yours is certainly a well though-out rationale, I tend to agree more with Reinhard's arguments, so I won't repeat them here.
I just wanted to add my 0.02€.
It's undoubtedly true that you can abuse flowscript and implement too much business logic in it. At my company, we are probably guilty of this, in a sense. We tend to implement things with Javascript because the roundtrip time between editing and testing is so short: no need to recompile and restart the container to test results.
Our policy is that putting business logic in the flowscript is to be considered OK in a prototyping stage. Once the prototype is tested, you should reimplement it in a Java method or class. Of course, this takes discipline and sometimes the move-to-Java stage can be postponed (or forgotten) due to deadline pressure, as always.
But I have high hopes that we can have the best of both worlds (the speed of the scripting approach together with the proper encapsulation and type-safety provided by Java) *now*. The answer is the compiling class loader.
I've just begun experimenting with it and the ease with which you can edit your Java classes in an editor like Eclipse's (with on-the-fly error correction, support for refactoring, code-completion etc.) and have them automatically compiled and available looks very promising.
One more thing: you mentioned editing cocoon.xconf as a typical step when you're defining a new business object. Well, I see cocoon.xconf as something that should be hidden from view as much as possible. I don't want less-experienced developers touch it and risk breaking the build because of a misconfigured component. I don't even want myself being subjected to the pain of dealing with it.
IMHO, Avalon is much harder than it should be. If we have to live with it, for the time being, I want to implement a full-fledged Avalon component only for exceptional cases. I think a POJO, compiled on-the-fly and instantiated via cocoon.createObject from the flowscript, and maybe implementing some of the handful of interfaces that this method supports, is all that is needed 99% of the times. This is where your business logic should reside. Once your business objects are considered "stable", make a lib out of them and add the JAR file to your project.
Ugo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
