cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Howard" <coc...@leverageweb.com>
Subject RE: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?
Date Sun, 26 Jan 2003 03:07:17 GMT
> Java and C++ both have places to start. You can get a Hello World
> up in about 5 minutes.

I don't think you're asking for a "hello world".  I did a hello world within
a
few minutes of first downloading cocoon a year ago.  Put an xml file
somewhere.
Put an xsl file somewhere.  In the main sitemap, put
<map:match pattern="hellothere.html">
<map:generate src="myxmlfile.xml"/>
<map:transform src="myxslfile.xsl"/>
<map:serialize/>
</map:match>

and you're done.  You're a smart guy and you must have done this much by
now.

Where you go from there is different for everyone.  You want to
do EJB's, some people want to stick with static xml files, some people want
relational
databases, some want xml databases, slide, etc.  That's all very possible in
cocoon
but they are so different that it's made it tough so far to get the user
experience under control, as you've noticed.

What you've been asking for is legitimate but not currently easily
available.

I've heard you say:
1) Simple user experience.  Well, that's a little subjective because of the
many
different needs people are bringing to the table but I think everyone here
would like
to see that too and value your input on where that's missing.
2) Smaller, more self contained war.  I asked for that too when I started
with
cocoon and had to figure it out on my own unfortunately.  I sat down earlier
and went
through the steps of the build from source taking out everything optional
and wrote them down for you and the greater good in the wiki.  The war I
built is less than 5 meg, and worked right away.  If you're using jdk1.4 I
can send you the war.
   The longer term solution is being worked on and has come a long way
already from 2.0.x but it's in 2.1 which is just getting to alpha stage, and
so not appropriate for your needs yet.
3) The complaint about the number of jars I understand less, unless it was
related to cutting out what it unnecessary.  That can be overwhelming, but
the minimal build I've described and may one day be included in the
distribution has only what it needs, so you just leave the jars in there.
It does have 28 jar files in WEB-INF/lib (about half of what the full
version has) which sounds like a lot, but I don't yet understand your
concern there.  Cocoon has a sophisticated component based architecture.  If
a bug surfaces in the source resolving component, you will probably be able
to drop in a replacement for that jar and not have to worry about the rest
of Cocoon.  You can jar those all up together in one big collection if you
want for convenience if you need to start mingling them with other things.

> If you take the attitude "don't let the
> door hit you in the ass on the way out," then people will head
> out and make sure the aforementioned door doesn't strike. This isn't
> a game. Its not a toy. Its not something that can be said "like
> it or leave it." Its a technology. And the other newbies to this
> product are likely not as tenacious as I am and will say "well to
> hell with it." Cocoon needs some SERIOUS work in the usability
> zone. No no, I don't expect to understand it in 12 hours. Don't
> be ridicules. I do expect to be able to make a start on
> understanding it in 12 hours though. Having Hello-World up in 12
> hours is not exactly a steep request.

You're right about the work needed for usability, which is why we're
trying to help.  And you are helping us:

- What concepts specifically are the most confusing to you
from your perspective of just trying to get up and running now that
you've been looking around the available docs and samples (and where
are _they_ not much help)?
  The wiki has been helping to get new documentation up quickly,
so whatever specific discussion we can have on the list will be of
almost immediate benefit to others that come after.

- EJB use is not well documented and not very "slick" at the moment, but I
for one have been wanting to take a look at it.  Do you see yet how to
proceed, or can we help get you started?  You could easily have a generator
spitting out xml from an ejb tonight if you'll ask specific questions and
provide more detail about what is unclear to you.

>
> If the users have to build from source, which is NEVER a
> straightforward process, they will take off and find something
> easier. Ant,
> for example, is massively extensible....

Obviously that's why the binary distributions are there.  But as you've
pointed
out they are bloated for your deploying needs which is an excellent point I
think.
Follow the instructions I put up at the wiki or let me send you this war
file and
let me know if you think this is in the right direction.

> Right now I get the impression that if
> I ever did want to make my own generator, I would need to mount
> 50 jars into my NetBeans project. NOT AN OPTION. One jar, fine. 50,
> no.

I am not familiar enough with NetBeans to help you integrate there but maybe
someone else is.  Still, have you looked at the tutorial on generators I
sent you a link to?  The most complicated example there needs 4 jars on the
classpath.  In case you missed it, it's here:
http://xml.apache.org/cocoon/tutorial/tutorial-generator.html

I've just noticed that there have been some changes to the way excalibur and
avalon are distributed since I wrote that, so there may now be a few more
jars (and the names have changed - I'll get back with the details in a few
minutes.  The docs need to get updated there I think.)

> Cocoon is missing this layer of abstraction. The cocoon jar file
> should be packed with classes abstracting things out so people who
> don't know jack about Avalon can write a generator or action.
> There should be a single jar (perhaps with contained jars) that I can
> drop in some magic location and magically write cocoon apps.
> Configuring it should be a matter of minutes (if at all) not a matter
> of hours to understand. I don't care about setting the properties
> of the WML serializer. I'm not even going to use the WML
> serializer. My goal is to snap together a web site, route it
> through cocoon with my own sitemap and pipeline and go. Anything I
> don't specify or configure should DEFAULT to pre-configured settings.

Well, I don't know if completely hiding the existence of avalon from a
developer
creating a Generator or Action is a reasonable expectation, but it is
reasonable
to expect that in a short sitting you could get the basic concepts that are
crucial in writing Cocoon components.  Please note that most users that I
see on the
list don't in fact know anything about Avalon, but they are not trying to
write
Generators or Actions from scratch.  There are a few concepts that have been
introduced to facilitate that:

1) XSP.  I didn't like this at first but have grown to love it.  It is
really like JSP in the simplicity of use.
2) The stock actions and generators.  Again, I had to warm up to these, but
there is a lot of power there.  These don't exist at this point for EJB
interaction, but do handle other things that are very common: database
interaction, file system access, form validation etc.

Trying to help you,
Geoff Howard


---------------------------------------------------------------------
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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message