cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wechner <>
Subject Re: [FYI] usecase
Date Tue, 15 Apr 2003 08:45:26 GMT
Stefano Mazzocchi wrote:

>Today I went online with my latest creation which is
>entirely based on cocoon 2.1-dev compiled today. This says it all about
>how confident I am about the code we have in CVS.
>I want to tell you how I did it and why I choose it.
>The site is very small. The IA diagram []
>lists no more than 10 different pages or decks of pages. Moreover, I've
>done *all* the work by myself. Everything, from taking the pictures,
>graphic design, CSS/HTML creation, programming, installing.
>The result is:
> 1) no need for actions, everything is performed with 120 lines of
> 2) no business logic in the flowscript: I wrote a few java objects that
>implemented a really-poor-man file repository on top of the file system.
> 3) no use of XSP
> 4) use of style-clean XHTML for all document markup and velocity as
>template system for simple pages
> 5) no database. all information is stored in xml files in a virtual xml
>repository on disk.

what do you mean by "virtual xml repository" and how does it work?

> 6) header/footer are not cincluded by they are 'wrapped' by a
>'style.xslt' stylesheet at the end of every pipeline. This concept of
>XSLT style wrapping is pretty cool and *much* more powerful than any
>server-side-include paradigm.
> 7) the site contains a complete CMS in the administrative section. user
>authentication is done via flowscript, connecting with a very simple
>user registry fed with file. really-poor-man-acl, you
>could say.
> 8) the admin section is heavily DHTML-ized. It works on all 6th
>generation browsers and the user is able to upload images and such
>without requiring rountripping
>[by setting the 'src' property of an img with the value of the <input
>type="file"> it is possible to visualize the image the user is uploading
>right from disk, without requiring any rountripping. this improves the
>user experience *immensively*!]
>[also, using dom cloneNode() it is possible to keep on adding images in
>the form without requiring roundtripping.]

it would be nice to have something like that within Lenya. Would you 
like to share some of your code?
Maybe this could also be used for other stuff, such as for instance 
"links" to related stories, but instead of
reading from the disk, some dialog with the CMS should be started.  The 
same would be nice for loading
"multimedia-data" (image, audio, video) from a multimedia-repository 
located on the server (with some built in search functionality). Hence 
data could be easily reused.

>My experiences in DHTML programming with 6th browsers has been very
>positive. IE and Moz are pretty much compatible, there are only a few
>issues that really bug me:
> 1) if you have <div class="blah"> blah is found in div.class in mozilla
>but div.className in IE! sometimes I think those guys in redmond just
>need more sunshine. I ended up testing for 'document.all' to
>discriminate between the two DOM types.
> 2) the event model is *completely* different. there are tricks to make
>the same code work on both, but things like onclick(), onchange() and
>onfocus() never seems to work the same way. I ended up using
>onpropertychange() which is IE-specific. It is amazing how two different
>browsers can claim compliance with a spec, but still be completely not
>To be honest, I have to say this is not only Redmond's fault: the DOM
>spec lacks any connection with the system. So, it says that events are
>pushed, and what is their names, but not *how* and *in what order*!
>As a result, I wrote some 300 lines of javascript for the client side
>and only 4 of them were browser-dependent.
> 9) I used Mozilla for development. If you are using another browser to
>develop your sites, throw it away and use mozilla. If you haven't done
>so, please read:
>but even better, go to and download
>that awesome plugin that shows you the dump of all the headers that flow
>thru between you and the server. This saved me hours of cocoon-view
>based debugging, expecially on multipart forms. Not counting the ease of
>use of the javascript console compared to the stinking useless IE error
>popup window. yuck.
> 10) at the end, this is a web site designed with *extreme usability* in
>mind. I spent endless hours trying to remove *everything* possible from
>the site without sacrificing the information that the site needed to
>transmit. Also, the site is completely manageable by people who are
>barely able to read email.
> 11) despite the ability of IE6 on all machines that need to access the
>internal CMS, I decided *NOT* to use any contentEditable solution but to
>use pure forms for two reasons:
>   a) their content is always structured
>   b) web users are used to forms, but not to inline editable pages
>(yet, at least). Forms provide visual semantics which are generally
>understood, inline editing is not standardized and without proper visual
>indications, users assume that if it's not in a textarea, the content is
>simply not editable. I think that even in a future of advanced inline
>editing, forms will still have their pretty consistent usage because of
>the clear visual semantics that are associated to them.

yeah, we have made the same experience. But still it is important to 
follow both tracks and with XML
it's no problem to do that (at least theoretically).

>                                    - o -
>Lessons learned:
> a) cocoon can be very useful for small sites, but the hard part is
>*not* to use all its features and get down to easy stuff like a velocity
>template that generates XHTML. Still, it can provide very useful
>features even in that case (think style wrapping instead of
>header/footer inclusion)
> b) flowscript rocks the planet. it will rock even more combined with
>hot-deployable avalon components.
> c) LiveConnect (the glue between javascript and java) makes it hard to
>abuse the flow to write business logic in it. Even after a few lines of
>having to call the classes by their full package names, you spin it off
>into their own classes and call them. This turns out to be very
>straightforward and keeps the flow *very* clean.
> d) flow + inputmodules + redirection from flow totally substitute the
>need for actions in the sitemap. The elegance of the resulting solution
>is not even close to be action-based equivalent.
> e) sessions and continuations do need to cohexist and they do very well
> f) cocoon needs an xml repository as an avalon component accessible
>from the flow! the use of protocols is simply not enough for the kind of
>data manipulation required in seriously roundtripping webapps that have
>to mix, match and change stored xml content. This doesn't need to be an
>xml database, it could be a virtual file system on top of a blob-capable
>DB or a CVS view.
>Hope this helps.

sure it does.




View raw message