Re: [xmlc] XMLC_SOURCE_FILE problems

This is a multi-part message in MIME format...

------------=_1125539313-10599-344
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:57 AM 9/1/2005 +0200, you wrote:
 >I am generating the interfaces and implementations for my html pages with
 >the following ant task syntax:
 >
 ><xmlc
 >  verbose="on"
 >  srcdir="/webapps/myproject/root"
 >  sourceout="${target.dir}/xmlc/src"
 >  includes="**/*.html"
 >  options="/webapps/myproject/root/WEB-INF/options.xmlc"
 >  packagename="package.for.my.project"/>
 >
 >I want to keep my html files in my webapp's root directory (this seems like
 >what everyone would want to do) so that any html files that I don't have a
 >servlet to change with xmlc can simply be served as static html.
 >

Not a bad idea

 >But for some reason, when I go to call xmlcFactory.create(indexHTML.class),
 >it is looking for the html file in
 >"/webapps/myproject/root/package/for/my/project/index.html" instead of
 >"/webapps/myproject/root/index.html", where I want it to look.  This is
 >obviously due to the generated value for XMLC_SOURCE_FILE in the
 >implementation class.  Why, why, WHY would it set that to the package rather
 >than using the path it found the html file in under the "srcdir" that I
 >passed it?
 >

Because your build environment may have little to nothing to do with your 
deployment environment.  It may in your case, but it doesn't have 
to.  Additionally, although webapps seem to be the primary use-case for 
XMLC, there is nothing that locks XMLC into a webapp paradigm.  As such, 
there has to be a consistent place to look for the markup files that go 
along with XMLC-compile classes built with -for-deferred-parsing.  The only 
place where they can be guaranteed to be found without any extra 
configuration is in the same package alongside the respective compiled 
generated classes.

That said, one can override this behavior by configuring Reparse Resource 
Directories.  For an example, take a look at the Tomcat example app that 
comes with the distribution.  Take a look at the generated web.xml in the 
"build/webapps/xmlc/WEB-INF" directory.  Here are the context params that 
get put in web.xml...

<!-- See Javadoc for org.enhydra.xml.xmlc.servlet.XMLCContext for info on 
the param-->
   <context-param>
     <param-name>xmlcReloading</param-name>
     <param-value>reparse</param-value>
     <description> </description>
   </context-param>

   <context-param>
     <param-name>xmlcReparseResourceDirs</param-name>
     <param-value>D:\dev\xmlc\examples\tomcat\res;D:\dev\xmlc\examples\tomcat\res\pkg</param-value>
     <description> </description>
   </context-param>

   <context-param>
     <param-name>xmlcReparsePackagePrefixes</param-name>
     <param-value>xmlc</param-value>
     <description> </description>
   </context-param>

   <context-param>
     <param-name>xmlcReparseDefaultMetaDataPath</param-name>
     <param-value>options.xmlc</param-value>
     <description> </description>
   </context-param>

XMLCContext uses these parameters to configure the deferred parsing 
factory.  If you have at least one reparse resource directory configured, 
the deferred parsing factory will look there to find the markup files 
rather than the classpath.  But it is a good practice to always package the 
markup files in the package anyway in case you decide at some point not to 
configure at reparse resource directory.  This provides for nice fallback 
behavior.

The other nice thing about this is that if you update the files, they will 
get reloaded and display any new markup available (don't expect new Id's to 
trigger new getElemementFoo() methods, however.  That has to be done at 
compile time).  Note that if you are on a Windows machine (and maybe Unix 
as well), you should modify the files elsewhere and then copy over the 
existing file.  Windows ends up locking files once in use and you can get 
weird behavior.  Same thing with jars and such after they are loaded by the VM.

 >I have to have the "packagedir" parameter because I want to have more than
 >one xmlc project at a time, and they can't all be classes called indexHTML
 >in the root package.
 >

I'm not sure what you mean by "more than one XMLC project at a time"?  I 
would guess that if you had different projects, you'd have different 
packages and, probably, different webapps.  So why would IndexHTML 
conflict?  You'd have the same issue with two index.html files in the same 
webapp in the root of the webapp, no?  I guess I'm missing something?

 >Maybe I'm missing something, but it seems like my requirements of keeping
 >the html files in the web root and having more than one xmlc project at a
 >time would be quite common.  What can I do???
 >

Being able to serve markup files as resources, only based off the webapp 
path rather than off the package path (disregarding the ability to set up 
reparse resource directories) would be a nice feature.  It's possible that 
it could be supported, but it would have to be thought through.  I'm not 
sure of the time-frame of the change either?  Patches are more than welcome!

 >(and please don't say that I need to create a symlink for every html file!)
 >

please create a symlink for every html file!  Kidding, kidding.

Jake

 >Cheers,
 >Erik




------------=_1125539313-10599-344
Content-Type: text/plain; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: 8bit


--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

------------=_1125539313-10599-344--