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

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

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

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.

 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.


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

Hope this helps.

-- 
Stefano.