as I started this whole kettle of fish discussion, I fully support and use the sitemap, flowscript, jxt combination. in my opinion trying to use the sitemap to determine the flow of a site can become too complicated produce and maintain in a very short time! And as for the use of Avalon/Actions, that itself can be too complex a solution to most problems I have had to deal with...
Instantiating objects, and calling methods with the objects, within flowscript I find is not a problem at all. As flowscript is the most straight forward platform to determine site flow within cocoon, and the data determines the flow, it seems to me to be a logical place to deal with your objects. Of course this is all dependent on what it is you wish to achieve!
Peter On 3 May 2004, at 14:23, Carmona Perez, David wrote:
I agree, I tried to make my own business objects in cocoon.xconf, and it's quite complicated.
I only use it input modules and things directly related to Cocoon.
-----Mensaje original----- De: Ugo Cei [mailto:[EMAIL PROTECTED] Enviado el: lunes, 03 de mayo de 2004 11:32 Para: [EMAIL PROTECTED] Asunto: Re: JXT or XSP?
Ralph Goers wrote: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]
************************************************************* Este correo ha sido procesado por el Antivirus del Grupo FCC. *************************************************************
************************************************************* Este correo ha sido procesado por el Antivirus del Grupo FCC *************************************************************
--------------------------------------------------------------------- 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]
