Re: XMLC CVS update...

Hi David,

I'm just wondering if XMLCDeferredParsingFactory supports loading XMLC
documents compiled in different Locales.  The way Barracuda supports
different locales is to use:

DefaultDOMLoader.getGlobalInstance().getDOM(MyXMLCPageHTML.class,
iLocale);

Actually, DefaultDOMLoader doesn't have anything to do with
XMLCStdFactory.  It is a generic DOM Loader and getDOM simply
returns a Document object rather than anything XMLC specific.


For instance, in the Barracuda Config app, the following class files
exist:

ConfigHTML.class
ConfigHTML_de.class
ConfigHTML_en.class
ConfigHTML_es.class
ConfigHTML_fi.class
ConfigHTML_fr.class
ConfigHTML_pt.class
ConfigHTML_sv.class
ConfigHTMLImpl.class

The original HTML file has one or more properties file associated with
it:

Config.html
Config.properties
Config_de.properties

The "Config.properties" file is the fallback and defines all
the keys that the other localization properties files refer to.

The result is:
Config.html
Config_de.html
Config.xmlc
Config_de.xmlc

The contents of Config.xmlc is:
-generate both

The contents of Config_de.xmlc is:
-implements org.enhydra.barracuda.config.xmlc.ConfigHTML

And, of course there is the options.xmlc with stuff like:
-delete-class discardMe

The Localize taskdef is run on this to generate:
ConfigHTML.java
Config_de.java
ConfigHTMLImpl.java


Now, I'm pretty sure that XMLCDeferredParsingFactory doesn't take this
into account since this is a Barracuda-invented mechanism.  However,
should something like this be supported natively in XMLC?  I'm just
wondering if this stuff, developed by the Barracuda project shouldn't
just be incorporated into XMLC because it is so XMLC specific?  Both
XMLCStdFactor and XMLCDeferredParsingFactory should probably support
localization whether the mechanism ends up looking exactly like how
Barracuda does it or whether Barracudas localization mechanism is teaked
to match up better with how the XMLC developers think it should
work.

Thoughts?

Jake

At 11:37 PM 11/22/2002 +0800, you wrote:
> ii. Replace
> org.enhydra.xml.xmlc.XMLCStdFactory with
> org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory in your
> code. XMLCDeferredParsingFactory extends XMLCStdFactory so you shouldn't
> have to change your codes. It should be a drop in replacement.
>
> It should be noted that XMLCStdFactory object only serves as a document
> class loader and document object initializer while
> XMLCDeferredParsingFactory perform additional caching operation on the
> html pages searching. If the program creates a new Factory object to load
> documents every time, you may consider to change your codes to share
> Factory to avoid performance penalty while using reloading.
>
> I am not considering to make a singleton out of the Factory. There are
> situation that multiple factories are necessary due to different
> configurations in the page setting.
>
> iii. Locating HTML pages. By default, the HTML pages are loaded along the
> classpath. This requires copying the html source into the classpath for
> deployment. The XMLCDeferredParsingFactory won't work without being able
> to locate the source file. The rule to locate the HTML file is in the
> directory of the pacakge of the document object and the original page
> file name.
>
> For example,
>
> com.foo.bar.testHTML compiled from test.html would look for the html
> pages located in com/foo/bar/test.html
>
> The following parameters in XMLCDeferredParsingFactory can be used to
> configure the behavior of the loading:
>
> addResourceDir():
>
> Add a new directory to search for the html page.
>
> addPackagePrefix():
>
> Add a package prefix to be remove while searching the document.
>
> For example, if you set a com.foo.bar to this prefix, it will search
> com/foo/bar/test.html and test.html in the class path and resource
> directories for the html file.
>
> David