Re: Thought on future of XMLC

Hi David,
   This sounds like a really interesting idea, however it's not really
XMLC anymore, it's a different paradigm.  It doesn't compiling anything.
I would suggest that this would be a separate package.  I think it could
share the output and lazydom packages.  This would also keep from
break existing XMLC users, as this will be completely incompatible.

It would be interesting to compare applications developed in this way
with the current XMLC and Barracuda

David Li <david@xxxxxxxxxxxxxxxxx> writes:
> 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.

Yes, it didn't take long to figure out that a package like Barracuda
was essentially for doing complex things. 

 
> 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.