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

Gregor J. Rothfuss wrote:

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

Have you seen it in action somewhere?

btw, here is the full thread:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105036235512487&w=2

thanks

Michael

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