> 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.
Yes, that is a deterrent to adoption. The strange thing is that it can be
easily fixed imho. What im talkign about is componetizing the distribution.
Hide anything the user doesnt need to routinely play with. The cocoon.xconf
file for example. I hear that I shouldnt be touching it. Fine, put it away in
a jar. Make it include any local user override of that file (via simple XML
include mechanism) and put the defaults away. Package the jars all into one
and label it cocoon-all.jar. In the online docs it would say "well drom the
cocoon-all.jar into your tomcat lib directory or in your war and off you go".
What we are talkign aobut isrepackaging. Some ant work. some config work and
thats it. Low budget solutions to high budget issues. Then what a user sees
when he gets to cocoon.war is something like the following (in XML notation):
<quote>
Getting Started guide:
To get started in cocoon you need to download the cocoon distribution war.
Inside the lib directory you will find cocoon-all.jar This is the core cocoon
classes and everythign you need to start developing with cocoon. Included as
well is the cocoon-dev.jar. This file contains the developer interfaces to
cocoon, such as for creating custom generators, and nothing else. It is
provided as a convenience means for developers to compile their custom
genrators and other extensions without havign to deal with the entire
cocoon-all.jar.
Inside the full kitchen sink version of cocoon.war we have the entire cocoon
web site represented. It contains numerous examples and documentation. What
is important to know is that the only files you really need are
WEB-INF/lib/cocoon-all.jar WEB-INF/web.xml, a sitemap, and your own stuff. So
your basic cocoon application war would look like the following
<war-file>
<directory name="WEB-INF">
<directory name="lib">
<file name="cocoon-all.jar"/>
</directory>
<file name="web.xml"/>
</directory>
sitemap.xmap
</war-file>
The cocoon-all.jar could alternatively be placed in the lib directory of
Tomcat if you dont wish to have it in every one of your war files. In
addition it should be noted that it is rare that you will have to modify the
web.xml. Remember that cocoon *IS* the servlet. You are merely extending that
servlet with your own content and potentially special classes. You may have
to create a deployment descriptor for your specific application server if the
need arises, but the web.xml is somethign you should only rarely modify.
The sitemap is the core of the cocoon process. it describes how the data
flows from generation through to serialization. It is through defiining
sitemaps that we map URLs to these various pipelines. For example a single
url might be mapped to take mycompany.xml and use an XSL sheet to translate
it into HTML. Another URL might be mapped to a pipeline that converts that
same XML sheet to WML for display on phones.
So, lets get a minimal distribution of this thing running.
Start off by creating the above structure. For your first sitemap put in the
following ..... <include hello world sitemap/> now create the following two
files. Firs an XML file with our greeting. <include hello.xml/> finally
include the followign strlyesheet. <include hello.xsl/> Now Drop in the whole
war into your sevlet container (or deploy it in your application server) and
point your browser at the url. Viola. you not have your first hello-world
using cocoon. Now is where it really gets interesting ...
</quote>
If I had had that file when I started, I wouldnt have been raising holy hell
on the mailing list. People like to work incrementally. Get them started and
then off to the races.
> 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.
Whap! You hit it right there. And thats exactly what im doing. Im under the
gun to get an interface that allows multi content publishing out the door (or
in my case in my book) and the internals of this interface as irrelevant to
the book. I simply want a web front end to a powerful server side EJB
application.
> 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.
Yep. So why do MS products do so well? because even though they are pieces of
garbage, they dont require anyone to buidl from source.
> 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.
Oh i intend to work through the materials at hand and get a book on it when I
have time. Right now I dont. I dont even have time to write all these mails
but I think cocoon has enough promise and is important enough to merit it.
> 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.
Not if you dont want to beat them. If you do then you have to realize that
corporate mentality will weigh it up like this.
"Microsoft .NET is shit but I can et it working in 5 days. It probably wont
explode in the year and a half average people have before they switch IT
jobs. Cocoon wouldnt explode long term at all but then I have to justify
taking 3 weeks to learn it. Heck with it, Ill go to .NET and let someone else
clean up the mess later."
Lusy attitude? Yep. True? Yep. The only way you smack these guys down is the
same way tomcat smacked down asp. They put out a product that was easy to use
AND had tons of features and stability. Thats why asp is grossly outnumbered
by jsp despite all MS's efforts. Thats why apache has tomahawked IES. You
take advantage of that "i need it working in 5 days" mentality and then put
on "oh as an aside, after you get cocoon working it will be so damn stable
that you will be the hero of the company:" Were talkign product survival
here. The battlefiedl of computing is littered with great products that didnt
do 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).
No, not at all. No responsibility. That does depend on your goals though
doesnt it? If you are writing a product for the heck of it, in your spare
time, cause your girl is on vacation, who cares. If you actually want people
to use this product in a business and to take over the niche the product
fills than you have a burning need to start thinkign about cold hard truth.
> 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.
The irony is that what I feel is needed probably boils down to a bit of ant
work and the above mentioned gettign started guide. I dont even think it
merits another project though there would be arguments for drop in jars for
various componets instead of lumping it all together. But hey, lets lump.
Lets just HIDE everythign the user doesnt need to see. Lets make a dev jar
for those generator writers. Lets make a minimal war target in the ant file
and put it up for FTP. Whammo. What we are asking for and at low cost. Im not
even remotely qualified to do it however. It would have to be someone who
knows cocoon intimately. And honestly I dotn want to do it. My primary
concern is y book that im writing. Im a ***WAY USER*** of cocoon. Not a
developer of it. And it is from this perspective that I come in. With a
little ant work, perhaps some work to hide the config files and only append
overriding files if a user decides to override settings, and a bit of
documentation, you have just transfomed cocoon from a way confusing animal to
a roraing tiger that is easy to deal with but ripe with potential.
> 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
-- Robert
>
>
> --
>
>
>
> 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]>
>
---------------------------------------------------------------------
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]>
