> There are good reasons why ctwig is hidden now, mainly because it fell out > of step with documentation as that moved on. I have intended for sometime > to update the stuff so that it can go back into the "mainstream" examples > but it has had to drop down my priority list for various reasons. Having > said that, IMHO there are a shed load of places (including the dist docs) > that cover basic xml/xslt/xsp handling with Cocoon. So why is it that > people feel Cocoon is too difficult to get into? Does ctwig still fill a > gap? Could we have even more simple examples, wars etc that people can just > pick up and use? > > I am personally very concerned that the perception is still of Cocoon as a > difficult beast to get into. The recent threads on this are a kick up the > backside for me as far as getting ctwig up to date goes but it would be nice > to know that that is still what is needed. I promise to work on this in the > very near future so let me know if you think anything else needs doing to > make being a Cocoon newbie as welcoming a prospect as possible
GOOD! This is my idea of the right attitude. People seem to fail to realize that if I didn't see the potential of the product, I wouldn't bother wasting several hours of my time typing up very long emails on the subject. What you need in my newbie opinion. 1) A deployment version with one jar containing all the required CORE libraries in that jar. This jar would contain avalon and excalibur and the rest but wouldn't bother to mention it. That would stop "jar shock" that the newbie encounters when popping open the web-inf/lib directory. I think my exact words were, "Holy shit?!?!? What do I really need?" 2) A single built war file with hello world. All it does is spit out hello world through a little XSLT template. That's it. This is where newbies want to start. Start small and work your way up. 3) Componetize optional features. Give them separate configuration files and keep them separate. 4) Change the distribution. You get either a minimal (which is required stuff +hello world) or medium (which contains some samples) or kitchen sink (the current distribution). 5) Remove anywhere where cocoon user has to know about avalon or excalibur. Most of us don't much care. When we write a generator we want to implement an interface and say "uhh, my generator is here with this class name" and go with it. If I need to mount more than one jar, something is borked. Basically just facade all the entry points into cocoon with interfaces. its low a low budget task that goes a LONG way. 6) Remove any need to build from CVS. I downloaded the module, all 61 megs of it and now I expect to spend 20 hours to just get a minimal build working. Users don't want to have to build the product. Maybe 1% of ant users ever bother to build it. Same for tomcat and the other popular apache products. 7 and not a priority but would be nice) Change logging to use Log4j. Its won the race. Even the logging in jdk has been beaten bloody by log4j. The other logging frameworks might as well concede. --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
