[
Lists Home |
Date Index |
Thread Index
]
- From: Edd Dumbill <edd@usefulinc.com>
- To: xml-dev@XML.ORG
- Date: Tue, 9 May 2000 00:22:48 +0100
I've been spending some time looking at XMLWidgets [1], a way of rendering
XML documents available for Zope [2].
What XMLWidgets does is basically run a bit of script to create an HTML
representation when a particular element is matched. More than one
script may match an element: it is up to that script to say whether or
not it should run (ie. is my parent "sect1"? OK, then I'm the "title"
you're looking for).
In fact the "scripts" I mention are really objects, which have a method
for rendering a DOM node and one returning a boolean value when queried
to see if the render method should be activated for the node in
question.
This is quite a neat way of creating an interface. Elements can
then have intelligent programmatic objects assigned to them to take care
of their rendering. XMLWidgets takes it one step further: because we
have a DOM we can also edit the node in question. Part of the example
code shows a very simple HTML & forms editing interface for XML. So
objects that "know" how to render and edit an element's contents can be
collected together to create a composite editing interface.
In various unfinished conversations with Peter Murray-Rust I've
discussed editor functionality like this. While XMLWidgets is obviously
specific to the Zope platform, I wonder whether this approach could be
used elsewhere.
A "bundle" could contain XPaths, so the controlling editor knows when to
activate a particular object, as well as rendering and behavioral code
(let's say the rendering could be done with XHTML, or perhaps XUL, and
behavior programmed with JavaScript). With such a framework quite
complex editing widgets could be evolved for datatypes and document
fragments and collected together into an editing interface.
I'm sure that some of this must have been done before, and I'd love to
be directed to it if it has. What I think would be fun, and I believe
incredibly beneficial to the cause of editing on the Web, was if an open
API could be evolved to support such a framework. The idea would be to
make it as open as possible, with a minimum desirable requirement that
it could be implemented in the current generation of emerging browsers,
using XHTML, ECMAScript, SVG (and perhaps XUL), and readily plugged into
other applications that required editing functionality. That said, I
don't see why alternatives for Swing, Tk etc. can't all be somehow
offered.
[Perhaps this is what XForms is all about, anyway? However I believe all
this could be done with existing standards.]
Pointers welcome. If anyone's done something like this then I think a
wider audience should know about it!
-- Edd
references:
[1] http://www.zope.org/Members/faassen/XMLWidgets
[2] http://www.zope.org/
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|