Re: Thought on future of XMLC

Hi Jake,

sorry to not explain properly, I guess some other did understand me only because I was 
mentioning this somewhere else before.

When the DOM tree is created, there are a lot of nodes which will not be changed by the 
programm. (Mostly a application program only changes nodes which have an id attribute) So 
there are whole subtrees of the created DOM tree, which will never be changed by the 
application. This subtree is created from an html-string (a substring of the original 
html-page). So if you want to output such an unchanged subtree, you could output the 
original string from the html file. For generating the output from the DOM, xmlc runs 
through the hole tree, even through these unchanged nodes and generates the html. If it 
had a refernce to the original html, it could output the part of the orioginal html it 
was created from.

The current time consumption for outputting html is quite high as you might know. But 
there are other ways to speed up as well. So the thing in question between me and mark is 
whether it is better to use the original html string or the html produced by the DOM.

Is that understandable?

Arno

Jacob Kjome wrote:
> Hello Arno,
>
> I feel your pain.  Let me see if I understand the issue, though.  You
> want XMLC, at compile time to compile only those things that have been
> edited in the page since the last compile?  I'm not sure that's
> possible?  Maybe if it did some relective comparison of the original
> generated file against what it currently generates and buffers all
> warnings and then only outputs the warnings that deal with the DOM
> nodes that changed?  Again, I'm not sure that's possible.
>
> Am I understanding you properly?
>
> Jake
>
>
> Tuesday, November 26, 2002, 3:14:04 PM, you wrote:
>
> AS> Hi Jake,
>
> AS> what you wrote is exactly what I did the last 3 years using XMLC. However, on the various 
> AS> projects with XMLC i have seen
> AS>   - HTML developer mostly don't produce legal HTML (often I educate them what legal HTML 
> AS> is and want not)
> AS>   - HTML developer don't use HTML Tidy, even if I install it on their 
> desktop.
> AS>   - there are some cases where illegal HTML is wanted, like the 'absmiddle'-attribute. 
> AS> Netscape and IE support some proprietary HTML attributes, which will cause warnings in JTidy.
>
> AS> HTML developers have a hard time already getting their code to run on all desired 
> AS> Platforms (IE, Netscape 6, Netscape 4,...) which is a big pain. Now we are asking them 
> AS> that their code should additionally be compatible with the W3C HTML 4.0 spec. I worked 
> AS> with designers from frog design, they got mad at me when I told them they couldn't use 
> AS> the IE and Netscape proprietary tags / atrributes.
>
> AS> The way HTML developers work is to view their HTML in all different browsers and if it 
> AS> looks good then its ok. And nobdy cares about the summary attribute in table-tags, which 
> AS> will cause warnings in the compile process. Java developers also refuse to fix them, 
> AS> because there are so many of them and they always are in a hurry. So the compile process 
> AS> is always full of JTidy warnings, and it is just too easy to overlook the important ones.
>
> AS> That is why I like to see XMLC change the original HTML code as little as 
> possible.
>
> AS> does that make sense to you?
>
> AS> Arno
>
>
> AS> Jacob Kjome wrote:
>
> > > 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
>
>
> AS> _______________________________________________
> AS> XMLC mailing list
> AS> XMLC@xxxxxxxxxxx
> AS> http://www.enhydra.org/mailman/listinfo.cgi/xmlc