Chris,
So, you take advantage of the '-implement' option in the XMLC
defining interfaces across different presentations, right? Hmm, I
haven't used that for a long time but it's a good point on the strength
of XMLC.
I think this thread is getting interesting. All feedback and
suggestion are valuable. Thanks and keep them coming.
David
On Thursday, Nov 21, 2002, at 19:04 Asia/Shanghai, Chris Webb wrote:
Mark,
I agree with you on this. This change would be a completely different
beast to the current XMLC. If we lose the convenience methods then we
would lose the ability to create interfaces to abstract the dynamic
requirements of each document and thus compile time checking of
dynamic content compliancy. We use these dynamic content interfaces
extensively for multiple look and feels for HTML, WML and VoiceXML.
Chris
Mark Diekhans wrote:
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.
_______________________________________________
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
| 