cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <DHo...@csir.co.za>
Subject Re: Action Vs Logicsheet
Date Thu, 03 Aug 2006 06:32:05 GMT
ML
 
I agree pretty much with everything you are saying here;
my main point about the original question vs. all the stuff that
came afterwards was just that the developers with experience have 
to be a little careful about reeling off long list of possible technologies
based on their own experience, even when its carefully qualified.
 
I think too, that before we rush into giving advice, we need to
check what the poster actually needs - "logic sheets vs actions"
may get to "flow script + built-in transformers" IF that is appropriate
for the users situation; if they are already a full-on Java guru with 
extensive experience in other web applications and frameworks, 
then we could start laying out the "high" road (or, more likely, roadS)
 
Aside: do you know if any progress was ever made in the adoption
of authentication into flow??
 
Derek

>>> Mark Lundquist <ml@wrinkledog.com> 2006/08/03 02:28 AM >>>

Hi Derek,

On Aug 1, 2006, at 11:54 PM, Derek Hohls wrote:

> ML
>
> 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"

Right... and I said "neither, use Flowscript or Javaflow instead".  I 
think that's a reasonable answer!  I feel like we'd be doing people a 
disservice not to warn people off of XSP, because IMHO the docs don't 
do a very good job of that yet...

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

Whoa, whoa!  Nobody said that.  I just tried to explain some things 
about my personal style of Cocoon development, e.g. I eschew pipeline 
components that are called for effect rather than for data, because 
that doesn't "feel right" to me.  I tried to qualify that with enough 
"YMMV" statements, etc., maybe you missed where I said this:

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

I just don't use SQLTransformer or SendMailTransformer, and I explained 
why I don't, that's all! :-)  I'm not trying to stop anyone that feels 
those are a quicker path to what they're trying to accomplish.  It's 
more like I'm trying to show others that have similar "taste" to mine 
w.r.t. declarative/imperative that there are other alternatives.

> 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
> 100%
> 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.

I think someone (I want to say Sylvain) came up with a nice framework 
for SQL access from flowscript a while back.  I haven't had the chance 
to play with it, but it looked like it would be ideal for simple 
CRUD-type stuff.  It looked like exactly the kind of thing you're 
talking about.

Also I remember a discussion back in '04 on the dev list having to do 
with the authentication framework.  Someone had the idea that that auth 
stuff should be refactored so that the core of it was usable from 
flowscript, and then the pipeline components would be implemented on 
top of the flow-friendly API for those who want to use it that way.  I 
liked that idea.

> My 2c is that this would be a set of
> built-in
> 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.

N.B. the OP was asking about the choice of writing logicsheets (Java + 
XSLT) vs. custom Actions (Java with understanding of Cocoon internal 
contracts, Avalon lifecycle interfaces...), so his question never 
really fit your profile of "minimal Java knowledge needed".

Best regards,
*ml*


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




-- 
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
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 
 
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 
 
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
CallCentre@csir.co.za.


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


Mime
View raw message