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]>
- Re: Cocoon is complex, HOLD... Antonio Gallardo
- Re: Cocoon is complex, ... Robert Simmons
- RE: Cocoon is complex, ... Geoff Howard
- Re: Cocoon is complex, ... Robert Simmons
- RE: Cocoon is complex, ... Geoff Howard
- Re: Cocoon is complex, ... Robert Simmons
- Re: Cocoon is complex, ... Antonio Gallardo
- Re: Cocoon is complex, ... Nicola Ken Barozzi
- Re: Cocoon is complex, ... SAXESS - Hussayn Dabbous
- Re: Cocoon is complex, but worth... Robert Simmons
- Re: Cocoon is complex, but ... Lajos
- Re: Cocoon is complex, ... Robert Simmons
- Thanks for the book! Antonio Gallardo
- Re: Thanks for the book... Lajos
- Re: Cocoon is complex, but ... Niclas Hedhman
- RE: Cocoon is complex, but worth it!... Geoff Howard
- Re: Cocoon is too complex for consumption? e nio
- RE: Cocoon is too complex for consumption? Jeremy Aston
- Re: Cocoon is too complex for consumptio... Robert Simmons
- Re: Cocoon is too complex for consum... Miles Elam
- Re: Cocoon is too complex for co... Robert Simmons