[Lenyacms-dev] using more dhtml in the authoring area

his fileupload concept sounds pretty nifty, far better than
our seperate screen.

i will put in a feature request

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

-- 
Gregor J. Rothfuss   [email protected]  +41 1 272 9161
                     Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS      http://www.wyona.org http://www.wyona.com 

OSCOM 3 - Third Open Source Content Management Conference
May 28th - 30th 2003, Harvard University, Cambridge, MA, USA
http://www.oscom.org/Conferences/Cambridge/