Re: Thought on future of XMLC

Hi Arno,

Seems to me that if your HTML developers aren't writing valid HTML then
they aren't doing their job.  You might point them to the W3C's HTML
validator and tell them to run it through that until there are no errors
and try to get rid of all warnings as well.  Then tell them to run
it through JTidy.  There should be significantly less problem output
at that point and everyone will be happy.

http://validator.w3.org/

Jake

At 11:42 AM 11/26/2002 +0100, you 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