I think you might already be there. Currently the concept of cocoon is a great one. I create a piepline and cocoon shunts it from a to b, applying the transforms and so on. Great development effort. Pardon the language but its a shitty user effort. Just look at one of your paragraphs in the linked archive.
<quote> "If we don't do this, not only Cocoon will get bigger and bigger (and start appearing more as a distribution of technologies, than a framework), but users will find it harder and harder to modify it for their specific needs." </quote> And that is the crux of the problem. Whoever is heading the project seems a bit confused. People dont want to MODIFY cocoon. They want to USE cocoon. They want to install cocoon's mechanics, then drop in their pipelines and go. Cocoon is now trying to do all sorts of things that dont need to be done imho. The number of features is so staggering that gettign started is near impossible. But as I get more into the product, I find myself saying, petulantly, "But I just wanted the pipeline!" And that is all that I wanted. To have a pipeline. To be able to say to cocoon, "Yeah, well ... in your pipeline whenever someone hits URL x, go to pipeline Z and run my custom class (which connects to ejbs and so on) and transform it with stylesheet Y and give it back to the user. "But you arent understanding how cocoon works Robert!" BINGO!! You hit it right there on the head. I dont want to understand how it works. As a user Im not interested. When reading the JBoss documentation, I skip over all the architecture stuff and the development stuff. As a user, this stuff is irrelevant to me. Object oriented programmign is supposed to guarantee to provide me with an interface and then implement some functionality. How? Who the hell cares? Im a user of it. My prime computing expertise is in the back end side of EJBs and issues that pertain to them. I want to USE cocoon, not develop on it. Possible solutions to this. 1) Rearchitect cocoon to implement some sort of deployment mechanism, such as COB. The problem here is that then you have to get that working with application servers and so on. The other problem is inertia. Gettign the masses of developers to learn a new-unstandardized deployment mechanism. 2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download JBoss and they are like "well tomcat is included." I say "cool" and drop in my wars and go. If cocoon had a basic mechanism install that could be installed into tomcat than the situation would be aleviated. Users of the product drop their wars into tomcat as normal with a sitemap file in the WEB-INF directory and their special generators an so on in the classes directory. Cocoon magically wires together the pipeline. No worrying about how to configure cocoon or what properties to give it or so on. Thats left to advanced users under the heading of "customizing your install". At any rate I can see the learning curve for this product is steep. And cocoon is mainly going o suffer from people like me. People whoe would love to use it but dont have a month to blow trying to get a technology to work that is merely suppsed to be an EASY way to develop a polymorphic presentation layer. Lastly, flaming is not an option. These are the opinions from a newbie comming into cocoon. Readers of this list can flame all they want but that is just hiding from the very real problems. -- Robert ----- Original Message ----- From: "Steven Noels" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 25, 2003 3:43 PM Subject: Re: Cocoon is too complex for consumption? > Jeff Turner wrote: > > > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2 > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2 > > oh, but that is unfair since you are a Cocoon committer and you have > easier access to such things... not! ;-) > > </Steven> > -- > Steven Noels http://outerthought.org/ > Outerthought - Open Source, Java & XML Competence Support Center > Read my weblog at http://blogs.cocoondev.org/stevenn/ > stevenn at outerthought.org stevenn at apache.org > > > --------------------------------------------------------------------- > 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]> > --------------------------------------------------------------------- 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]>
