Hi Robert -

Ok, my turn to weigh in.

First off, one first principle about any technology is that it's usability and suitability are largely subjective. Over the years, I have found that many technologies - JSP, EJBs, PHP, Perl/CGI, ActiveX, etc. - can work great if YOU like them and know how to use them EFFECTIVELY. And the same holds absolutely true with Cocoon. Sometimes you like it, sometimes you don't. For some jobs it rocks, for others a simpler approach will get the job done as well, if not better. THERE IS NO OBJECTIVE RIGHT OR WRONG. Put it another way, you cannot compare Cocoon with ActiveX, Perl, JSP or anything else - it is all apples and oranges.

Though I'm a Cocoon book author, I can tell you I myself sometimes get fairly pissed with Cocoon. Only recently I was coding up a simple, though lengthy, form in Cocoon using an XSP with the formval logicsheet, when I started getting an error that I was exceeding 66535 (or whatever) bytes for a method. Grrrrr. Luca will affirm that I was not feeling too kindly towards Cocoon that week. But in the end, (thanks to his client-side validation mechanism) I recoded and am fairly happy with the result. Should I have chosen Cocoon for this? Maybe not, actually. I probably put in more hours with this project than I would have using a JSP. But now that I'm done, I can modify the form to fit the client's changing needs much more easily than had I used a JSP. On the other hand, when I added credit-card capabilities to my site, I never even once considered Cocoon - I rolled a servlet with my own helper objects and am totally satisfied with the result. Point is, Cocoon is no magic bullet but then again, nothing is.

You make an excellent point that I have to agree with: it is hard to separate the Cocoon developer from the Cocoon user. To put it another way, you have to be prepared to be a bit of a Cocoon developer to be an effective Cocoon user. Frankly, yes, that can be a deterent to adoption. If you are under the gun to get some multi-output app up and you are looking at Cocoon stricly as a user of the technology yes, you might have to learn more than you bargined for. But that is the nature of this particular beast, just like it is the nature of M$ products that you know next to nothing about how they operate (until you find yourself hacked through one of their many security holes). Again, you can't compare the two - apples and oranges.

Absolutely, Cocoon is complex, and large, which I personally don't care for. But the flip side is that you can also do many, many, many things with Cocoon. If you like such complexity and flexibility, and care to take the time to work through the materials at hand (like mine and Jeremy's book ;) ), you will be happy with the results.

I also must agree with you and Hussayn about the business aspect of Cocoon. Having consulted at all layers of IT, I know what people look at. And yes, Cocoon can fall short for the reasons mentioned - usability, time-to-get-running, documentation, abstraction from details, separation of developer/user knowledge, etc. Business does judge harshly, though perhaps unfairly. Certainly, we serious users will all sneer if a pile of MS sh*t is taken more seriously than Cocoon. But, then again, there is a point. MS may have the usability (or perhaps the perception of usability) edge on Cocoon. But, here is the hard part, it is NO ONE'S JOB TO CHANGE THIS. This freedom from accountability is both a strength and weakness of OSS in general. One the one hand, someone with a great idea can start something like Cocoon, but conversely there is no implicit responsibility to an end-user like you (and the others who periodically raise the same objections).

If someone wants to position Cocoon for the big time and compete on the usability front with the big commercial software products, then that person/organization can do something about it. Many of the current developers and users of Cocoon don't need more than they have and are neither concerned nor required to be concerned with this debate. If you want to change it, put together a project - email me offline and let's talk. I love the idea. But that is the only way it will be done - nobody actually has the responsibility to do anything. No one involved with Cocoon has the job to capture "the minds and hearts of web publishers". If they don't want to, that's just fine. And if, as a result, some other products does end up capturing the minds and hearts of web publishers, that is fine too.


Regards,

Lajos


--



Lajos Moczar
----------------------------------------
Open Source Support, Consulting and Training
----------------------------------------
Cocoon Developer's Handbook
(www.amazon.com/exec/obidos/tg/detail/-/0672322579)

_ _____
/ \ /
/___\ /
/ \ /____

http://www.galatea.com -- powered by AzSSL


---------------------------------------------------------------------
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]>

Reply via email to