RE: Thought on future of XMLC

Hi guys,

If you look at byte code generation, may I suggest you consider 
using the ObjectWeb ASM project. It is easier to use and much 
faster at run-time than BCEL.

see http://www.objectweb.org/asm/index.html for more information

Thanks,
Christophe

Christophe Ney
Hypermedia System Consulting
WEB Engineering for Virtual Communities
http://christophe.batisseurs.com
mailto:christophe@xxxxxxxxxxxxxx
phone/fax +33 4 78 94 85 53
mobile +33 6 61 48 85 53 

> -----Original Message-----
> From: xmlc-admin@xxxxxxxxxxx 
> [mailto:xmlc-admin@xxxxxxxxxxx]On Behalf Of
> David Li
> Sent: Thursday, November 21, 2002 1:33 PM
> To: xmlc@xxxxxxxxxxx
> Subject: Re: Xmlc: Thought on future of XMLC
> 
> 
> How about moving the class generation to runtime. In your reloading 
> codes, the elements referred to by the accessor methods are 
> synchronized at runtime. The current code generating style is similar 
> to the style of BCEL (bcel.sf.net) and this package support 
> generating/loading new classes at runtime. This way, the 
> compiler will 
> generate only interface for compiling time checking and the impl 
> classes will be generated at runtime.
> 
> I am using BCEL to support loading of uncompiled new files and it's 
> getting close to working now. I have to rewrite much of the 
> ClassGenerator in term of BCEL, thu.
> 
> David
> 
> On Thursday, Nov 21, 2002, at 19:36 Asia/Shanghai, Richard 
> Kunze wrote:
> 
> > On Thursday 21 November 2002 12:04, 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.
> >
> > Same here, I use the conevenience methods quite often, and for much 
> > the same
> > reasons. But I definitely see that there are cases where 
> they are not 
> > needed.
> >
> > I'd like to support both in XMLC, and I think the best way 
> to do this 
> > is to
> > make the code generation process easier to change - 
> probably by making 
> > it
> > template driven.
> >
> > What do you think?
> >
> > Richard
> > -- 
> > Richard Kunze
> >
> > [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
> > Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
> > http://www.tivano.de, kunze@xxxxxxxxx
> >
> >
> > _______________________________________________
> > 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
>