cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <DHo...@csir.co.za>
Subject Re: XML updating as well as publishing
Date Mon, 04 Mar 2002 09:05:39 GMT
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 <r.t.l@bigpond.com> 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: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message