Re: Giving up! Cocoon too big, slow and confusing
I understand the complaints and agree with many of them, but I think that they are somewhat abstract or ambiguous. may you detail them so that they can be solved? it would be very helpful for all of us. Thanks to all the contributors to the cocoon project, it is a great product, but remember that one of the principles of programming is being humble to accept that things can be improved. Regards for example Documentation is scarce [ what part is scarce? all of it? XSP? ] Documentation is outdated [the same] few examples [which functionality needs more examples urgently?] stabilization [any comments? ] etc - Original Message - From: "daniel robinson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 27, 2002 11:23 AM Subject: Re: Giving up! Cocoon too big, slow and confusing > My .02, > > Thanks to Eric, Argyn and John for their honesty. And thanks to all of > the Cocoon developers for their hard work and vision. I would like to > add my comments to the reality check that is going on. > > I have over 17 years experience in the industry and have led developer > teams working on commercial software projects. I am an expert Java > programmer as well as C/C++ and others. I have worked on multiple > operating systems. I love a challenge. I'm not bragging (believe me I > don't think any of this stuff is anything to brag about in the REAL > world :) ), but I want to do a level-set as to who is doing the talking. > > I embraced this project because: > > 1) It had the Apache "stamp of approval" > 2) It said it was > version 2.0 > 3) The technological vision and approach seemed (and still seem) to be > the correct one. > > What I wanted: > > 1) To get a simple web site up fast and lay the groundwork for > subsequent versions (see www.vsolano.us). > 2) To use open source for all the right reasons. > > What I experienced: > > 1) An incredibly steep learning curve that has no end in sight. I have > NEVER worked on a project where I spent a hard 6 weeks slogging through > a technology and had NO IDEA when it was going to end. > 2) Documentation is not usefull - sorry. I've tried and tried. The > closest it has come to being useful is that after I've spent hours on > something and asked questions on the mail lists I have been able to go > back to it and say "oh.. that's what they meant" > 3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking > at the change logs for potential hints at what was necessary was a > non-starter. > 4) Generally helpful but inconsistant responses from the mail lists. > You should seriously consider joining the two lists as all it is doing > right now is making me have to search both lists for everything that i'm > looking for. Many of the questions were answered in a way which built > character but were much too cryptic to be helpful to anyone who comes > later. (I'm sure this is because the really knowledgeable people are > spending too much time answering e-mails). > > My conclusions: > > 1) Almost by definition this should not be a released product - sorry > but true. Someone should define what is meant by alpha, beta and > released software - also the meaning of point releases. > 2) I don't have time to read the source code - not because I can't or > won't from some misplaced belief that it shouldn't be necessary - > because I don't believe it would be time well spent - too much of a lack > of basic doco to make it worth the time. > 3) I will continue to maintain the current web site in Cocoon while I > research alternatives. I am going to keep an open mind and hope that > the forthcoming books will be of assistance - however I don't see how > this will be since there have been significant changes (forms and > authentication system to just name a few at the feature level) since > those books have gone to publishing. > > Also - please see my comments inline below - > > > Eric Sheffer wrote: > > >I completely agree with Argyn's and John's comments here. > >But, I don't think the sentiments expressed are unique to > >the cocoon project. > > > >I'm a big proponent of open source software. I try to use it > >and recommend it whenever I can. However, I can't spend two > >weeks just getting up to speed on something. I have to be > >productive quite soon after picking it up. I'm busying 50 to > >60 hours a week doing what my job demands of me, so I don't > >have a lot of extra time to devote to learning how to use a > >product, much less debugging or coding one. > > > Big agreement - I see my involvement as learning what I can, writing the > occasional FAQ and helping out on the mailing lists. > > > > > > >I still want to stay ahead of the curve, and learn new things > >and use new technologies. But, many open source projects > >make this very difficult. So if I could be presumptuous, here > >are some suggestions I'll offer to make life a little easier > >on us early
Re: [Juglist] Struts 2x vs larval Cocoon?
Hi, I am new in this forum and in cocoon, but it seems very promising. I found your reply very interesting and complete too. I also think that JSP are far from being the best solution, even with struts. but I was using struts with velocity and it worked very well. The doubts that I have about cocoon are performance and tools. I work with XMLSpy from altova and it supports very well XML in general and XSLT in particular. It is not integrated with cocoon but it is a very good tool for the task (XSLT), so the only thing that I am dubitious is performance: is there a benchmark or a comparison against something else somewhere? thanks for any commentary Jorge DeFlon - Original Message - From: "Andrew C. Oliver" <[EMAIL PROTECTED]> To: "cocoon users" <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 8:05 PM Subject: Re: [Juglist] Struts 2x vs larval Cocoon? > > > > Thomas L Roche wrote: > > > > >Struts can do pure-XML: see > > > > > >http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt_p.html > > > > > >But can Cocoon be made to handle JSPs? Why I ask: > > > > > >Yes, Cocoon is cool, and JSPs are icky-poo. If one is developing a new > > >site, from scratch, Cocoon would seem to be the way to go. However, > > >there are a lotta JSPs out there, and one can reasonably surmise that > > >the vast majority of Java-ish websites have at least some legacy JSPs. > > >So consider the possible thought processes of members of two groups of > > >Javans as they plan future activity: > > > > > > > > Like this (haven't tried it myself)? > > > > http://xml.apache.org/cocoon/userdocs/generators/jsp-generator.html > > > > >* site developers/maintainers > > > > > > Unfortunately only a tiny minority are at present fully XML/XSL > > > compliant. (I suspect: feel free to confirm/confront with real > > > data.) One suspects the vast majority are "vanilla" Model 1, with a > > > minority having gone to something like Struts, Velocity, etc. These > > > folks aren't especially stupid or lazy, but they've got other things > > > to do, and they've got legacy that is "good enough." > > > > > > If a "typical enduser" is motivated enough to go XML-centric, > > > wouldn't it be a lot easier and less risky to migrate toward > > > something like Struts (2 or 2x), than to Big Bang straight to > > > Cocoon? (I know about Struts--I neglect Velocity etc because I know > > > so little about them.) Or is it Real Easy to migrate JSPs to XSPs? > > > > > > > > Cocoon is what I like to think of as 2.0-centric. Meaning it has a > > higher "initial cost" but if used well, should > > reduce your cost of maintaining it over time. Its not the first release > > that usually hurts, its the second...third...etc. > > Costs go up as your software continues to develop. Cocoon can help with > > this by more completely seperating > > your style, data, logic, etc. (as you cross the learning curve of > > Cocoon and use it in a couple apps, that learning curve goes down) > > > > Is Cocoon appropriate for you farm of dreamweaver users? Probably not. > > But Really if you think about it neither is JSP. > > (I hear Velocity is nice for that) I suspect as the tools improve > > Cocoon will be better for this as you can seperate your applications > > more as far as logic and style and content, etc. XSLT has a bit of a > > learning curve, but I often wonder if I'd find it so hard if I were less > > of a programmer type. I think there is a lot more opportunity for > > non-programmers to work with the style XSLT in the end. But case in > > point. . . those tools aren't there yet. > > > > I don't feel that its any less risky to adopt Struts and migrate to > > Cocoon than just goto Cocoon with maybe JSPs running through the JSP > > generator (based on the assumption that the JSP generator is a workable > > solution) and migrate those to XSPs/etc over time. The areas I'm most > > concerned with Cocoon have to do with performance under load. Then > > again, if its good enough for NASA.. (no mars lander jokes or you > > get thwapped!) > > > > >* tools builders > > > > > > I'd like to work on Cocoon tooling, and I suspect many managers > > > would too. But they've gotta think about how much resource they can > > > devote to any particular project, and what the market for their > > > product would be. And, again, incrementality (of effort) and > > > marketing (of product) would both seem (IMHO) to favor going toward > > > Struts 2x. > > > > > >These concerns would be mitigated if there was an easier migration > > >path to Cocoon. (I.e. a larval stage before going to pupa :-) > > >Is there? Or am I missing something? > > > > > > > > Above, you see the JSP-generator. Next I give you XML-Form which even > > states that its heavily influenced by struts. > > http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html > > -- Danger, its work in progress. This is the last major hole in > > Cocoon, its nearly plugged (
