Arno,
I believe your issue with outputting the original HTML string for nodes
unmodified by the programmer is provided by the LazyDOM functionality.
This functionality also improves performance.
Regards,
Chris
Arno Schatz wrote:
Hi,
little late, but here are my $0.02:
The generated methods have been working very well when we used to
program directly with the DOM API.
Besides using a presentation framework there is another reason not to
use them in some projects: In the current project most XMLC-ids are
optionally (means I have to check if the exist in the HTML before
using a setText(String text, String xmlcID) method.
However in the development process I am facing another problem:
HTML designer are not used to compiling when they work with HTML (to
see the results integrated with the application) and checking for some
difficult to understand warnings from JTidy.
They are more used to just change it and then look if it is ugly or not.
Right now XMLC changes even those portions of the HTML which have not
been touched in the DOM tree. A usefuul feature in my eyes would be if
a DOM Node was not changed by the programmer then XMLC would output
the respective part of the original HTML string.
Right many people overllok the JTidy warnings and if the resulting
HTML does not look ok, a long process of searching starts.
Also a topic which comes up if XMLC should be used or not is of course
performance. But I guess you are already aware of that.
-Arno
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
_______________________________________________
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
| 