cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Simmons" <deri...@arcor.de>
Subject Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?
Date Sun, 26 Jan 2003 03:18:38 GMT
The biggest concept that has me is. "Ok so this is cocoon including everything
but the kitchen sink... so where do I start on my OWN site? Do I need to copy
this enormous cocoon config file? Haven't they ever heard of defaults? Do I
really need to hand modify all his stuff? Why is everyone telling me to build
the blasted thing from source? Cocoon.xconf ? Do I need this in my new war? Holy
Christ there are allot of jars (28 is still allot .. prepack them in the
distrib). Logikit? I use log4j for everything else. After all its the best
logging package ever made! What's with logikit?"

Those are the things that pop to mind.

Other things vary such as "why the heck wont JBoss let me redeploy this sucker?"
One question I got when I undeployed it from JBoss and dropped it back in and
then hit the URL and watched IE wave its flag at me for 5 min in some sort of
endless loop.

-- Robert

----- Original Message -----
From: "Geoff Howard" <cocoon@leverageweb.com>
To: <cocoon-users@xml.apache.org>
Cc: <derisor@arcor.de>
Sent: Sunday, January 26, 2003 4:07 AM
Subject: RE: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?


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


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