cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <>
Subject Re: Action Vs Logicsheet
Date Wed, 02 Aug 2006 06:54:12 GMT
Obviously Cocoon does offer multiple paths to a solution; and it
seems this debate of what constitutes "good" or even "acceptable"
paths comes up time-and-time again - unfortunately usually when 
a relative newcomer wants advice.
The original, seemingly-innocent question was:
 "How I could choose if I need an action or a logicsheet" 

And we are now getting to "dispense with the built-in transformers";
and moving to "Go Forth and Learn Hibernate and Spring"!

Sorry - but I do disagree strongly with this; Cocoon by itself has 
perfectly competent set of  tools in its tool-box to let you get at
of what you need for 90-95%% of the time... assuming "standard" web 
apps. For an average developer, learning Hibernate and Spring is a 
MAJOR hurdle and time-investment and, lets be honest here, the
documentation and guidelines to get all these working with Cocoon
is shaky at best.

Somewhere, somehow, this community needs to get a "simple 
roadmap for using Cocoon AS IS"  (ie. no plug-ins, add-ons, bonus 
frameworks etc. etc.) in place.  My 2c is that this would be a set of
transformers (SQL, send mail etc) along with flow (and CForms); there 
are solid examples of these in place already, which could be extended 
further as needed.  Minimal, if any, Java knowledge is needed and you 
can be productive relatively quickly.  If this level does not offer the

power/flexibility you need  i.e. you have very demanding requirements 
or you'd simply like more toys to  play with, there is a wide scope 
beyond this for lots more.


>>> Mark Lundquist <> 2006/08/01 08:14:45 PM >>>

On Aug 1, 2006, at 9:54 AM, Martijn C. Vos wrote:

> Mark Lundquist [] wrote:
>> Note: I would avoid a design that called for any kind of custom
>> transformer that's meant to be used for its side effects... that
>> probably indicates an abuse of the sitemap. Pipelines should be for
>> generating data.
> Why?

Good question :-) I started asking myself that, right after I posted 
that opinion.

In Cocoon everything is mediated by the sitemap. So there's always a 
pipeline, so what difference does it make whether that pipeline invokes

a transformer or dispatches a flow function? It's just one "tag" 
(<transform>) vs. another (<call>), so who cares?

To me, some things feel declarative and some things feel imperative. 
Declarative things feel like they belong in the sitemap, and imperative

things feel like they belong in flow (or below, in the model layer). 
Shoehorning imperative-feeling things into the sitemap feels wrong to 
me... so does imperative processing for things that feel like they 
should be in the sitemap (or to get rid of the sitemap or make it less

declarative, e.g. "why can't the sitemap just be a script, it would be

so much more flexible"?).

> There are lots of popular transformers that exist almost
> entirely for their side effects: the sql, sendmail, sourcewriting
> dasl transformers all exist entirely for their side effects;

Indeed. But notably,

1) Those are all pre-flow solutions that were created before it was 
figured out that flow was needed;

2) I don't use 'em... I use Hibernate for all DB stuff, and for sending

mail I use either the Spring mail component, or the Cocoon MailSender 
component, called directly from flowscript or from Java (in the model 

3) Just because something exists, doesn't mean much... XSP exists too,

but I wouldn't touch it w/ a ten foot pole (that's 3.048 meters for the

rest of the world :-)

Anyway, like I said that's just what feel right for me, not trying to 
be dogmatic...


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

This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice 
CSIR Copyright, Terms and Conditions 
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

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

View raw message