On Friday 03 December 2004 21:20, Sylvain Wallez wrote: > The list of possible uses cases [3] is quite impressive: > - the expression evaluator can be used... ahem... as yet another EL for > our template engine :-) > - the script evaluator can be used for CForms event handlers > - the class body evaluator can be used to write JS-like code for > flowscript (we don't need a class name, but just methods) > - it provides a compiling classloader.
Once upon a time, the founders of Cocoon taught me about FS, and I am getting the feeling that it has been slowly creeping into Cocoon for so long now, that one can't see the forest for all the trees ;o) Honestly, how many *users* of Cocoon manages to keep up with the ever longer list of so called features, many doing the same thing in different ways? I don't, otoh, I don't do a lot in Cocoon (helping out on a couple of small sites) but I try follow the dev@ list since the start in 99(?). IMVHO, Cocoon needs to reduce features, not add them. Boil down to a nice core that works, and then create a couple of subprojects for 'work styles'. I think the barrier of entry to Cocoon is ever-growing, and I have heard a couple of times from friends; "It is too complex." Before protests about the modularity and that you can start small, I want to this is "impressions" and "first impressions", they last... In marketing terms, Cocoon right now is somewhat vulnerable to competition that nails down the *need* of the users and delivers it in an easy to comprehend package. My two cents to the recent set of proposals to extend Cocoon even further. Cheers Niclas -- +------//-------------------+ / http://www.dpml.net / / http://niclas.hedhman.org / +------//-------------------+
