Re[2]: Thought on future of XMLC

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



-- 
Best regards,
 Jacob                            mailto:hoju@xxxxxxxx