cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From beyaNet Consultancy <beya...@ntlworld.com>
Subject Re: JXT or XSP?
Date Mon, 03 May 2004 13:46:21 GMT
Hi,
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:u.cei@cbim.it]
> Enviado el: lunes, 03 de mayo de 2004 11:32
> Para: users@cocoon.apache.org
> 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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> *************************************************************
> 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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message