> 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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
