Robert Thanks for the detailed reply - and link to Stafano's comments.
Limits - are really more short term things - lack of documentation - particularly well-commented and worked-through examples. The whole 'live editing' and content/user management framework side of things - which seem they like *should* be easy to have in place 'on top of' Cocoon but are not there yet. At present, I think its also safe to say that Cocoon is not a one-step installation (the majority of the posts on the users group testify to that); and think that the sooner it gets the more widely used it will be. The current examples are also 'tastes' of how to do things, rather than fully-fledged mini-apps that can be taken 'as is' and rapidly customized for particular situations. I do not think these would be hard to create; possibly some donations from the user community are in order (as per the ones that Andreas has made on the cocoon-center.de site). Again these need to be installed and working out-of-the-box to get new users up-to- speed asap. These comments reflect more my concerns as non-Java guru, whose focus is on wanting to provide end-users with working systems as fast as possible, without wanting to get 'sucked' into the source code, but at the same time building with an architecture that is solid, extensible and makes sense; perhaps I am asking for the best of all worlds... Cheers Derek >>> Robert Leftwich <[EMAIL PROTECTED]> 04/03/2002 10:35:56 >>> At 06:10 PM 4/03/2002, Derek Hohls wrote: Although I am a keen Cocoon user, I have become increasingly aware of its limits. Well, I'm just starting out, but I like what I see so far (particularly what I see in the recent roadmap email). Would you care to elaborate on its limits? If you are willling to sacrifice a fully XML-centric app, you may want to look at Zope - just been past there and its a bit of shock to see how much it offers 'out-of-the-box'. This articles contrasts the 2 systems: http://www.arielpartners.com/arielpartners/content/public/topics/technology/technologyReviews/zopeVsCocoon This page on the Zope site has some interesting 'quick looks' at running a web-based puiblishing system (aka CMF): http://www.zope.com/Demos/ Otherwise the zope.org site has a lot of links and introductory items. I'd be interested to hear your thoughts around this topic... Zope is quite amazing, up to a point. Some 18 months - 2 years ago we built 2 quite complex web-apps with it and it was certainly very easy to get up and running. The biggest problem with it, was its closed nature (i.e. everything in the ODB, everything done via its own proprietary templating language embedded into the html) and there were a lot of quirky syntax things that you had to do 'just so' otherwise it didn't work. When we attempted to find additional people to work on the system we came up blank for a long time, eventually finding people who just had so many problems picking up the syntax (both Python and templating) and the implementation, that it was not worth continuing with it. At least it appears that they are attempting to address some of those limitations. We've since implemented web-apps using Java technology and have been very happy with the products, tools, libraries (open source and others) and the language. Our biggest problem is finding a presentation layer toolset we are happy with. After our bad experience with Zope, we were not in favour of embedded templating languages that pollute the html, etc (see below for Fowlers comments on that approach) and we want something as standards-based as possible, hence the interest in Cocoon (I did spend some time looking at Cocoon1 last year but felt the design was too limiting, however Cocoon2 is a different kettle of fish). I've used Enhydra Presentation Objects, Barracuda (I was/am a committer on that project) and the Bebop UI library from ArsDigita's ACS system but I have yet to find exactly what we need (Bebop came close, but ArsDigita future is uncertain). As for the Ariel article did you see Stafano's comments on the dev list (I came across them while searching for something else), see http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg11592.html for the start of the thread. Robert PS Martin Fowler says the following at http://www.martinfowler.com/isa/serverPage.html "Template View has two significant weaknesses. Firstly the common implementations make it too easy to put complicated logic onto the page, thus making it hard to maintain - particularly by non-programmers. You need good discipline to keep the page simple and display oriented, putting logic in the helper. The second weakness of Template View is that it is harder to test than Transform View. In most implementations Template View are designed to work within a web server and are very difficult or impossible to test outside of a web server. Transform View implementations are much easier to hook into a testing harness and test without a running web server. " --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
