Ugo Cei wrote: <snip/>
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 worth a lot more to me:)
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.
That's what I do, too.
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.
In my personal view (which is probably faulty) I see cocoon as some sort of application container, because it can (and does) run more than one application. In that sense, it is a bit like tomcat.
And as with tomcat, I think only common libraries should be configured in a cocoon-spanning fashion (as is done with cocoon.xconf) or installed in a similar fashion (as in WEB-INF/classes). Classes which are only required for a single application (business logic) have nothing to do polluting the namespace and global file space. It also makes it harder backing up a particular application. I do make an exception for temporary objects (like compiled on-the-fly classes); I don't really care where they are put as long as they can be cleaned out easilly and don't clash with other classes.
This is what is withholding me from using to much business logic implemented in Java, and causes me to move more logic than I care for to flowscript. Even though I think Java/Eclipse is a far better environment to develop logic (In contrast to you, Ugo, I don't care much for Javascript. I happen to like typed variables and a compiled environment as it allows easy detection of potential trouble, even without running through every line of code:).
I do think the compiling class loader like the one used in xsp will do much to pull the logic back to Java, where it belongs, in stead of to the flow script.
Leon
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
