cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carmona Perez, David" <>
Subject RE: JXT or XSP?
Date Mon, 03 May 2004 13:23:59 GMT

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 []
Enviado el: lunes, 03 de mayo de 2004 11:32
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


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


To unsubscribe, e-mail:
For additional commands, e-mail:

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:
For additional commands, e-mail:

View raw message