Re: [xmlc] XMLC_SOURCE_FILE problems

At 01:12 AM 9/1/2005 -0700, you wrote:
>
>--- Jacob Kjome <hoju@xxxxxxxx> wrote:
>> 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.
>
>Fine, I understand this.  I still think the default
>behavior should be to look under the "srcdir" that you
>passed into the xmlc generation program.  But that's
>my opinion, and if the override works, then I don't
>really care.
>

How would a class at runtime know this info without it being 
hardcoded?  So, then your srcdir is at "C:\dev\myproject\src".  Then you 
send the binary to someone to run on their machine.  They don't have the 
srcdir, they just have a binary jar to work with.  How does XMLC find the 
files without being configured in this case?  In the case of having them in 
the same package as the class they get built with, they can be pulled from 
the classpath.  So, not matter where the program is run from, XMLC can find 
its markup.  If you explicitly provide one or more reparse resource dirs, 
then you can override this default behavior.  The point of the default is 
that it can be counted on to work, regardless of the environment.  Of 
course you have to copy the files to the package, but that's pretty basic 
when using a build tool like Ant.

>> 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.
>
>I'm sorry, but the only place they can be "guaranteed"
>to be found is in the srcdir  that you generated the
>classes from.  Anywhere else would require you to move
>them.
>

Ant to the rescue.  It should be part of your compilation step.  Compile 
the classes, and copy the files to the respective locations of the 
classes.  See the Tomcat example app to see this working (the .xmlc files 
are copied to the package, but the markup actually isn't copied because we 
set up reparse resource dirs anyway, so I didn't bother for this example, 
although it is better practice to copy the markup as well).

>My desire to have my build and deployment environments
>seems very sane.  It's much simpler for web designers
>to understand than to know that they have to dig into
>a 4-deep directory structure to find the html files.
>

Why would a designer have to dig for the markup?  I never said force a 
package structure on the source markup files.  That's what <copy> is for in 
Ant and "xmlcReparseResourceDirs" and "xmlcReparsePackagePrefixes" are for 
in web.xml (or programatically on the deferred parsing factory).  Your 
source can stay wherever you want it.  I really get the feeling you haven't 
looked at the Tomcat example app very closely, if at all, as it allows for 
exactly what you are trying to do.

>> 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...
>>
>> 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.
>
>This doesn't work for me at all.  Let me show you what
>I'm doing and tell you what I want it to do, and maybe
>you can tell me where the misunderstanding is...
>
>My html files:
>/webapps/myproject/root/index.html
>/webapps/myproject/root/marketing/faqs.html
>
>As mentioned before, I'm generating the xmlc
>interfaces with a packagename of
>"package.for.my.project", and a srcdir of
>"/webapps/myproject/root".  So my generated classes
>are:
>package.for.my.project.indexHTML.class
>package.for.my.project.indexHTMLImpl.class
>package.for.my.project.marketing.faqsHTML.class
>package.for.my.project.marketing.faqsHTMLImpl.class
>
>With the following XMLC_SOURCE_FILE values,
>respectively:
>XMLC_SOURCE_FILE =
>"package/for/my/project/index.html";
>XMLC_SOURCE_FILE =
>"package/for/my/project/marketing/faqs.html";
>
>My web.xml:
>  <context-param>
>    <param-name>xmlcReparseResourceDirs</param-name>
>    <param-value>/webapps/myproject/root</param-value>
>  </context-param>
>
>In your example, you gave the xmlcReparseResourceDirs
>as an absolute path, so I did too (although "/"
>doesn't work either).
>

Tell me if the Tomcat example app works for you.  I want to start with a 
baseline that I know works for me.  I don't have a Linux development 
environment, so I haven't really tested it on a Unix system, although there 
is no reason I can think of that it wouldn't work?  If the Tomcat app 
doesn't work for you, then there's a bug to fix for configuring reparse 
dirs in unix environments (or the build file is windows-specific, but I 
doubt that).  If it does work, then we'll work on getting it working in 
your environment.  I think it will do what you desire.

make sure to define "xmlc.home" and "tomcat.home" in build.properties, such 
as...

xmlc.home=../../release (points to the directory containing the lib and 
build-lib directories)
tomcat.home=D:/Java/Apache/Jakarta/jakarta-tomcat-5.5.8

Then run "ant"

Then do "run-tomcat"

Open a browser to:

http://localhost:8081/xmlc/

Does it work for you?

>The way I understand things, there's no way this
>override would work, since it doesn't have the value
>"index.html" or "marketing/faqs.html" anywhere in the
>generated classes (without some intelligent parsing of
>the XMLC_SOURCE_FILE values).  So it will still be
>looking under the full package structure defined in
>XMLC_SOURCE_FILE, but looking for it in the dir
>specified in xmlcReparseResourceDirs.
>

... along with the reparse package prefixes.  If you doubt so much, then 
try the tomcat example app.  It should work and remove your doubt.  More 
below....

>> 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).
>
>I understand that.  It would be nice, however, to have
>an option to make the generated interfaces' getElement
>methods only return the base class Element rather than
>the specific subclass (e.g. HtmlDivElement), so that
>if you moved your "id" attribute from a <div> to a
><td>, it wouldn't need interface regeneration.  Is
>that clear?
>

Interesting idea.  Something to look into.

>>  >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?
>
>I mean that it works (finds the html file properly) if
>I don't specify the "packagename" parameter to the
>xmlc interface generation.  But if I don't specify it,
>my classes end up being indexHTML and
>marketing.faqsHTML.  So if I want to run two webapps
>(different root dirs) in the same JVM (same
>classpath), there's a conflict.
>

Well, thanks goodness for the "packagename" parameter, no?

>> 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!
>
>If the reparse resource stuff would just remove the
>package prefix from the path it looked in, it'd be
>great!

The reparse resource dir(s) should point to the base location you want to 
start looking for markup files.  More below...

>  You'd think that's what the
>xmlcReparsePackagePrefixes param might be for, but it
>doesn't seem to have any effect.
>

It does, but maybe not in the way your are thinking.  It lops off part of 
the package so that your markup files don't have to follow the exact 
package namespace as the classes.  For instance...

  <context-param>
    <param-name>xmlcReparseResourceDirs</param-name>
    <param-value>/webapps/myproject/root</param-value>
  </context-param>
  <context-param>
    <param-name>xmlcReparsePackagePrefixes</param-name>
    <param-value>package/for/my/project</param-value>
    <description> </description>
  </context-param>

That allows for the look up of "index.html" to be relative to the 
package.for.my.project package, because the package is implied.  Similarly, 
the lookup of "marketing/faqs.html" is implied to be in the package 
"package.for.my.project.marketing", just as if it has been taken from the 
classpath.

Note that in both params, multiple values are separated by the value of 
File.pathSeparator on the current system (":" on Unix, ";" on 
Windows).  The "xmlcReparsePackagePrefixes" paths would also have slashes 
specific to the filesystem ("/" on Unix, "\" on Windows).  Because of this 
platform specificity, I would suggest defining these context param values 
in an external configuration file such as Tomcat's context configuration 
file, using <Parameter> elements (See Tomcat docs).  This way, your web.xml 
doesn't become platform specific.  You, as the deployer, can configure this 
outside the .war archive.

If you use dynamic loading (loading a markup file without pre-compiling), 
then you should specify...

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

That will be relative to any one of the specified xmlcReparseResourceDirs

Don't forget to have the generated .xmlc files alongside either the 
respective classes in the classpath or the respective markup files in the 
reparse resource dir(s) (I always copy them to the classpath along with the 
classes).

Anyway, let me know if that works.

>>  >(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.
>
>Sounds like I might have to after all....  :-(

No, not really :-)

Jake

>
>Erik
>
>
>
>____________________________________________________
>Start your day with Yahoo! - make it your home page
>http://www.yahoo.com/r/hs
>
>
>
>--
>You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing
>list.
>To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws



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