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
| 