Zope DHTML and XHTML : Moving things to the Client-side
I think it worth to encourage zopelist to move more things to the client-side by modify a Zope fresh installation. I found out there are many things hard-coded in python or dtml in zope's source. There are some things which can be do better in the client side. For example, there were many dynamic folder tree writen in javascript which can be more responsible than the zope tree tag (which the change of the tree state require the help from server). I would like to urge zopelists to explorer the client side authoring which could actually give zope a dramatically change. 1. Remove those hard-coded parameters from the source and placed them in the folder tree as attributes which can be modified or overwrited by manage interface and acquisition. 2. Define the basic css (which zope.org have one) as default elements with the fress zope install. 3. Make the current Zope tag comply with xml standards : they should end with /> or accept an end tag. 4. Collect open-source javascript codes and convert them into zope products (like tree).
On Fri, 3 Mar 2000, Sin Hang Kin wrote:
There are some things which can be do better in the client side. For example, there were many dynamic folder tree writen in javascript which can be more responsible than the zope tree tag (which the change of the tree state require the help from server).
IMHO this would be a very bad idea, because not all browsers are able to use javascript. for example the tree tag works perfectly with lynx. This is really very nice, because often we can't do many things with text only browsers, but the tree tag is very powerful and lynx can use it: it's cool. bye, Jerome
I would like to urge zopelists to explorer the client side authoring which could actually give zope a dramatically change.
You may want to check out the Zope-Mozilla initiative (and the related Model/View discussion), which does something like this. It's on http://www.zope.org/Resources/Mozilla. As this is Open Source, contributions are more than welcome. Rik
Sin Hang Kin wrote:
I think it worth to encourage zopelist to move more things to the client-side by modify a Zope fresh installation.
I found out there are many things hard-coded in python or dtml in zope's source.
There are some things which can be do better in the client side. For example, there were many dynamic folder tree writen in javascript which can be more responsible than the zope tree tag (which the change of the tree state require the help from server).
I would like to urge zopelists to explorer the client side authoring which could actually give zope a dramatically change.
for better or worse ? ;)
1. Remove those hard-coded parameters from the source and placed them in the folder tree as attributes which can be modified or overwrited by manage interface and acquisition.
That could be good idea.
2. Define the basic css (which zope.org have one) as default elements with the fress zope install.
What would it add ? But a CSS-method or similar would be a nice addition. Or even a general TEXT-method, with Content-type: as an attribute, so I don't need to write <dtml-call "RESPONSE.setheader('Content-type'. .... for all non-html methods
3. Make the current Zope tag comply with xml standards : they should end with /> or accept an end tag.
Why ? As has been revealed in several discussions before, it would be very limiting for DTML to force compliance to XML (dtml tags inside html tags, etc) Making it only superficially similar would just confuse people.
4. Collect open-source javascript codes and convert them into zope products (like tree).
If you could integrate it nicely with other parts of zope it would be a welcome addition. But I doubt it would be easy, but if you can come up with a nice implementation, I'm sure it would be accepted in contrib. -------------- Hannu
Why ? As has been revealed in several discussions before, it would be very limiting for DTML to force compliance to XML (dtml tags inside html tags, etc)
Making it only superficially similar would just confuse people.
If you consider separate code and data. If you think about putting XMLDocument in real use. This is one of the possibility: using an xmleditor, the user can save the xmldocument to zope server as zope automatically make all parts of the document reusable as zope object (is it all what zope about? making a document into many small parts as each of them be re-usable object?) This is process by zope automatically, the author do not required to do extra works. The author can edit the document or part of it and view the final result if the xml-editor support this. To make this better, the author can embed dtml code in the xml document, which make the document be active and live. You may have a system automatically updated. Isnt it what zope designed to be? The document inside zope can have multiple view as we can have dtml-methods to transfer them into different view: html, xml+xsl+css, pdf, doc, etc... If dtml syntax is not xml-complience, all of these will not happen. A deeper change is to make dtml syntax more xsl like. I.e., make it block oriented. So, the author is forced to code in good manner, instead of the opening and closing tags were spearated into many places which I think is very bad for maintenance.
participants (4)
-
Hannu Krosing -
Jerome ALET -
Rik Hoekstra -
Sin Hang Kin