More comfortable DTML editing ?
Editing DTML in a textarea input is very annoying. Will there be a better solution in the future of Zope ? Andreas
Andreas Jung wrote:
Editing DTML in a textarea input is very annoying. Will there be a better solution in the future of Zope ?
We want to use Zope for data entry for our writers, so we want to develop some nice stuff, like Javascript Search/Replace and Javascript spellchecker. Together with <TEXTAREA WRAP> (attention DC - why isn't this the default in Zope?) that's a good start on a text editor. -- Itamar - itamars@ibm.net ---------------------------o----------------------------------------------o Perl/Gimp Greeting Cards | Trust? Ha! The US dollar is backed by ICBMs! | http://www.sealingwax.com | --Anonymous Coward, Slashdot |
On Fri, Oct 15, 1999 at 07:15:30PM +0200, Itamar Shtull-Trauring wrote:
Andreas Jung wrote:
Editing DTML in a textarea input is very annoying. Will there be a better solution in the future of Zope ?
We want to use Zope for data entry for our writers, so we want to develop some nice stuff, like Javascript Search/Replace and Javascript spellchecker. Together with <TEXTAREA WRAP> (attention DC - why isn't this the default in Zope?) that's a good start on a text editor.
I think there a at least two possibilities: a) some kind of java applet with basic text editing facilities. This should be easy to integrate. b) support for external HTML editors. The major point here is the exchange interface. Maybe one could use Webdav ?! Andreas
On Fri, 15 Oct 1999, Andreas Jung wrote:
Editing DTML in a textarea input is very annoying. Will there be a better solution in the future of Zope ?
Here part of a pipe dream I had recently: Create a Product called 'Forms'. It lets you build forms using various subobjects. eg. You would create a 'form', put inside it a 'button', and maybe a 'fieldset' which contains a load of 'radios'. You get the picture. It would be coded as DTML tags, probably one for each of the existing HTML form tags. What is interesting, is that the rendering of the forms doesn't have to be boring HTML, although it will default to that. For instance, I might set attributes that enable client side type checking in javascript, or selectivly enable/disable form elements. I might also, depending on the settings in a a cookie, run a Java applet (jpython anyone?) for nicer editing. This Java applet would start just doing syntax highlighting, but could then be extended to include editing mode (vi, emacs, Windows) depending on a cookie, client side DTML syntax checking, conversion of <!--#dtml tags to <dtml- tags, whatever. Once this basic framework is setup, it is then a case of rebuilding the DTML forms used by the Zope management interface to use the new Forms product. Suddenly, you have a management interface that is still usable with Lynx, but also provides an all-singing-all-dancing development environment if your brower is JavaScript 1.1 and JDK 1.1 compliant. <dtml-form action='gohere'> <dtml-fieldset> <dtml-textarea type=dtml name=text> </dtml-fieldset> <dtml-input type=submit name=submit value=submit> </dtml-form> Hazy section that probably won't work well: If all this is successful, add an attribute to DTML methods and documents to 'use smart forms'. If set, you just use standard HTML form tags in the edit windows and it actually stored as dtml-form tags. This is were it got all hazy, as external editors of which I know little start getting in the way :-) It would be nice if someone could create a HTML document in Claris home page, add 'type=html' to the textarea element, and when it is displayed from the Zope site, they get a nice GUI HTML editor embedded in their web page instead of their boring textarea. ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
On Sat, 16 Oct 1999, Stuart 'Zen' Bishop wrote:
On Fri, 15 Oct 1999, Andreas Jung wrote:
Editing DTML in a textarea input is very annoying. Will there be a better solution in the future of Zope ?
Here part of a pipe dream I had recently:
Just want to mention that I came acss a GNU java applet text editor called jext. http://www.chez.com/powerteam/index_n.htm It has an xml extensible gui, but I have not checked it as I do not have java installed. Maybe someone can check it out ... Pavlos
On Sat, 16 Oct 1999, Stuart 'Zen' Bishop wrote:
On Fri, 15 Oct 1999, Andreas Jung wrote:
Editing DTML in a textarea input is very annoying. Will there be a better solution in the future of Zope ?
Here part of a pipe dream I had recently:
This pipe dream already exists. Check out VisualZope (technology preview version 0.0.1) and see the webpage http://www.dansteinman.com/dynduo for details on how this was done. A new version will be out in a few weeks once the DOM patches filter through Cheers, Anthony Pfrunder Computer Systems Engineering University of Queensland
Anthony Pfrunder wrote:
On Sat, 16 Oct 1999, Stuart 'Zen' Bishop wrote:
On Fri, 15 Oct 1999, Andreas Jung wrote:
Editing DTML in a textarea input is very annoying. Will there be a better solution in the future of Zope ?
Here part of a pipe dream I had recently:
This pipe dream already exists. Check out VisualZope (technology preview version 0.0.1) and see the webpage http://www.dansteinman.com/dynduo for details on how this was done.
Yes, various related ideas have been floating around. My 'formulator' currently-vaporware approach wouldn't use dtml tags, but field objects in a special formulator folder, and an XML description to layout the user interface. Most of the info, like field width for a field, or possible data you can enter, or javascript validation, server side validation would be in the objects, though, and not in the XML, which is where I think this differs from VisualZope. I'd probably use XMLWidgets in some as yet unspecified way. :) Eventually VisualZope, XMLWidgets and Formulator will all converge into something coherent, hopefully.
A new version will be out in a few weeks once the DOM patches filter through
Which DOM patches are this? Did you notify Amos? I'm curious about them myself, too, as I ran into some problems with XMLWidgets about which I've been in communication with Amos. So please enlighten me. :) Regards, Martijn
On Mon, 18 Oct 1999, Martijn Faassen wrote:
Anthony Pfrunder wrote: [snippy snip]
A new version will be out in a few weeks once the DOM patches filter through Hmm, this might be a *few* weeks so don't hold your breath. I've got to fix that DTML ZClass problem first.
Which DOM patches are this? Did you notify Amos? I'm curious about them myself, too, as I ran into some problems with XMLWidgets about which I've been in communication with Amos. So please enlighten me. :)
Hi, I'll submit them again but basically this is how to patch it: * For all creation DOM methods (clone, createXX ...) you need to add some hidden magical methods to stop weird errors from occuring. Here is how: # This makes the aquisition path point to the current containing # document. These attributes doesn't exist after a creation call hence, # aquisition doesn't work properly. def XMLpatch(self, p): p.aq_acquire = self.aq_acquire p.aq_base = self.aq_base return p Then, for each creation call wrap it like such: def createTextNode(self, data): return self.XMLpatch(Document.createTextNode(self, data)) here, Document is an XML document and data is the actual content of the Text Node (I think). Cheers, Anthony Pfrunder
participants (6)
-
Andreas Jung -
Anthony Pfrunder -
Itamar Shtull-Trauring -
Martijn Faassen -
Pavlos Christoforou -
Stuart 'Zen' Bishop