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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
