Re: deferred parsing fallback?

Hi David,

I definitely like solution #1, but I'm not sure that is going to get
done, so I might have to live with solution #2.  Any idea if #1
would be implemented before the 2.2 release?  I'm not sure I'm
qualified to do it as I'm not sure where I'd start.  You or Richard
would have the easiest time doing this, but I understand the time
constraints and all.  Anyone else up to doing this or showing me how
(if it doesn't take too much explanation)?

Jake

At 08:00 AM 4/16/2003 +0800, you wrote:
> > I
> > guess I had assumed that deferred parsing was just an added capability
> > and that the standard XMLCStdFactory would still be able to load the
> > classes, albeit without deferred parsing.  This would make it so you
> > could compile with the possibility of deferred parsing, but then when you
> > didn't need deferred parsing turned on, the classes would be loaded like
> > normal which, I assume, is a bit less overhead. 
> >
> > Shouldn't there be a fallback; backward compatibility, if you will? 
> > Was this just not considered and so it wasn't implemented, or is it not
> > implementable?  Just wondering if I'm going to have to worry about
> > recompiling each time I want to change XMLC factories?  If so, this
> > means I have to both remove the option in my options.xmlc file and make
> > sure to change the DOMFactory to the appropriate one that won't blow up
> > when loading XMLC classes.   Hmmmm......   Any
> > solutions, or am I just going to have to live with a bit of extra
> > maintenance? 
>
> The StdFactory won't be able to load document class generated for
> deferred parsing. Fallback sounds reasonable thing to do but it's just
> not high on the ToDo list, I guess. I have ran into the issues recently
> with our app here and I just demand to do the recompilation whenever a
> factory change is necessary. 
>
> The class for the StdFactory has a bunch of codes for assembling a DOM
> tree and for the deferred parsing, the codes are done by the parser so
> they don't have to be in the generating classes. Deferred parsing offer
> everything of StdFactory without shortcoming and I think the intention
> now would eventually to replace the std factory with the deferred
> parsing. 
>
> So, I guess there are two solutions here: 
>
> 1. Implement the backward compatible document class generating. This
> shouldn't be very hard but tedious. It requires merging the std class
> generating codes with the deferred parsing generating codes. 
>
> 2. Just forget about the existing of StdFactory and start thinking
> Deferred parsing as the only factory. ;) 
>
>
> </blockquote></x-html>