Re: Thought on future of XMLC

Hello David,

I'm slightly confused with the JXPath approach.  Would we still be
working on a Java class that represents the DOM in Java or would we be
loading up a document at runtime and running XPath expressions on it?
If we are loading up the document at runtime, wouldn't this be a
performance issue?  I'm probably just missing something.  If there is
no runtime performance issue, then I am all for it.  However, this
seems like it would break compatibility with existing programs using
the convenience accessor methods.  I don't think it would affect me so
much since I use Barracuda's BTemplate and standard DOM for the most
part, but I imagine there are plenty of people out there that might be
concerned about the change.

BTW, would these types of changes mean that we are no longer dependent
on any particular version of Xerces?...or maybe not dependent on
Xerces at all?

Jake

Wednesday, November 20, 2002, 11:15:49 AM, you wrote:

DL> Hi,

DL>    Working on the next release of XMLC, I come to think about where to 
DL> go with XMLC in the future. The current reloading works by reparsing 
DL> the HTML/*ML documents, by passing the Java class 
DL> creating/compiling/reloading in the previous version. With this in 
DL> place, the next question is whether or not the Java wrapper of the *ML 
DL> documents are needed at all.

DL>    Currently, the Java wrapper of the document provides the following:

DL> 1. Generate convenient methods to manipulate simple text field using 
DL> span tag, e.g. providing setText* method for a given text tags with 
DL> particular ID.

DL> 2. Generate convenient methods for the element access, e.g. getElement* 
DL> for elements in the documents.

DL> However, for most non-trivial HTML programming, we go into heavy DOM 
DL> programming to access the documents mixing with these convenient 
DL> methods. In some case, totally forgo these methods and do everything 
DL> using the DOM interfaces.

DL> DOM API is low level and was originally defined in IDL for cross 
DL> language portability. It's tedious to use and anyone who has tried to 
DL> populate a table using DOM API could testify this.

DL> The new XMLC reloading has open up the possibility to get rid of the 
DL> Java classes and enable to dynamically add new documents into XMLC 
DL> system without source generation and compilation. However, with this 
DL> approach, we won't have the convenient methods for the XMLC class and 
DL> will have to deal with generic DOM.

DL> There are two possible solutions to provide a new programming interface 
DL> on top of the XMLC: a Document centric approaches using XPath or a Java 
DL> centric approaches using either JDOM or DOM4J. Both can probably be 
DL> provided together and give the choice to the users to pick their 
DL> favorites.

DL> I have been experimenting with XPath for a while using a package called 
DL> JXPath from Jakarta project. It uses XPath to address the elements in 
DL> DOM and can be use to replace the convenient methods generated by the 
DL> currently XMLC implementation quite easily.

DL> for setting text,

DL>    documentContext.setValue("id(foo)/text()", "New value");

DL> Just some random thought on the future of XMLC. I'd like to hear what 
DL> the community feel about the features needed to make XMLC a better 
DL> tools.

DL> David

DL> _______________________________________________
DL> XMLC mailing list
DL> XMLC@xxxxxxxxxxx
DL> http://www.enhydra.org/mailman/listinfo.cgi/xmlc



-- 
Best regards,
 Jacob                            mailto:hoju@xxxxxxxx