cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: [FYI] www.ormaz.it usecase
Date Tue, 15 Apr 2003 09:47:20 GMT

On Tuesday, April 15, 2003, at 12:19 AM, Stefano Mazzocchi wrote:

> Today I went online with my latest creation http://www.ormaz.it 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.

Thanks for this Stefano, I do promise to do something similar for the 
iNIVA site, but while I am still busy working on it, I don't have time 
;)

> The site is very small. The IA diagram 
> [http://www.jjg.net/ia/visvocab/]
> 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
> flowscript

good, it would be really interesting to see ....

>  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.

this would be interesting to see as well ;)

>  3) no use of XSP

good!

>  4) use of style-clean XHTML for all document markup and velocity as
> template system for simple pages

you like velocity, don't you ;)
tbh I have not used it .... my immediate reaction to seeing a page of 
velocity was yuk, that's ugly ;)

>  5) no database. all information is stored in xml files in a virtual 
> xml
> repository on disk.

nice, it would be great to hear more about this

>  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.

Hmmm, not entirely convinced yet ...


>  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 java.properties file. really-poor-man-acl, you
> could say.

now this is where I get really interested ;)

>  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*!]

very cool, I do this in XMLMind too ....

> [also, using dom cloneNode() it is possible to keep on adding images in
> the form without requiring roundtripping.]

<snip/>

> As a result, I wrote some 300 lines of javascript for the client side
> and only 4 of them were browser-dependent.

I always refused to work with dHTML, for these very reasons, hmmm, I am 
beginning to loose out!

>
>  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:
> http://devedge.netscape.com/viewsource/2003/mozilla-webdev/

yes, I used this lot, Mozza is top!

>
> but even better, go to http://livehttpheaders.mozdev.org 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.

Drag, I cannot get the plugin to load .... MacOSX?

>  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.

sounds like my client ;)

>  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.

hopefully this will change ....

> Lessons learned:
>
>  a) cocoon can be very useful for small sites,

agreed!

> 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.

yummy!

>  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.

yeah, this is good

>  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.

I forget about input modules WRT flow ....
What are you doing with them there?

>  e) sessions and continuations do need to cohexist and they do very 
> well
> already.
>
>  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.

Hmmm, interesting ...

> Hope this helps.

many thanks

regards Jeremy


Mime
View raw message