Chris,
LazyDOM can still be used as in-memory DOM. The current Java wrapper
basically wrap around the DOM document which can either be Xerces DOM
or LazyDOM.
David
On Thursday, Nov 21, 2002, at 01:44 Asia/Shanghai, Chris Webb wrote:
David,
If we lose the Java wrapper will we lose LazyDOM support or will that
functionality be encorporated the evolved form of XMLC?
Chris
David Li wrote:
Hi,
Working on the next release of XMLC, I come to think about where to
go with XMLC in the future. The current reloading works by reparsing
the HTML/*ML documents, by passing the Java class
creating/compiling/reloading in the previous version. With this in
place, the next question is whether or not the Java wrapper of the
*ML documents are needed at all.
Currently, the Java wrapper of the document provides the following:
1. Generate convenient methods to manipulate simple text field using
span tag, e.g. providing setText* method for a given text tags with
particular ID.
2. Generate convenient methods for the element access, e.g.
getElement* for elements in the documents.
However, for most non-trivial HTML programming, we go into heavy DOM
programming to access the documents mixing with these convenient
methods. In some case, totally forgo these methods and do everything
using the DOM interfaces.
DOM API is low level and was originally defined in IDL for cross
language portability. It's tedious to use and anyone who has tried to
populate a table using DOM API could testify this.
The new XMLC reloading has open up the possibility to get rid of the
Java classes and enable to dynamically add new documents into XMLC
system without source generation and compilation. However, with this
approach, we won't have the convenient methods for the XMLC class and
will have to deal with generic DOM.
There are two possible solutions to provide a new programming
interface on top of the XMLC: a Document centric approaches using
XPath or a Java centric approaches using either JDOM or DOM4J. Both
can probably be provided together and give the choice to the users to
pick their favorites.
I have been experimenting with XPath for a while using a package
called JXPath from Jakarta project. It uses XPath to address the
elements in DOM and can be use to replace the convenient methods
generated by the currently XMLC implementation quite easily.
for setting text,
documentContext.setValue("id(foo)/text()", "New value");
Just some random thought on the future of XMLC. I'd like to hear what
the community feel about the features needed to make XMLC a better
tools.
David
_______________________________________________
XMLC mailing list
XMLC@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/xmlc
--
Chris Webb
Voxsurf Ltd.
3rd Floor
Elme House
133 Long Acre
London WC2E 9DT
Tel. +44 (0) 20 7240 3621 x 206
Mob. +44 (0) 77 8639 2359
Fax. +44 (0) 20 7379 7573
e-mail : chris.webb@xxxxxxxxxxx
Voice Demo. +44 (0) 870 744 7223 http://www.voxsurf.com
Email disclaimer: This can be viewed at
http://www.voxsurf.com/disclaimer.html
_______________________________________________
XMLC mailing list
XMLC@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/xmlc
| 