Re: [xmlc] XMLC_SOURCE_FILE problems

--- 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.

> 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.

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.

> 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).

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.

> 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?

>  >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.

> 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!  You'd think that's what the
xmlcReparsePackagePrefixes param might be for, but it
doesn't seem to have any effect.

>  >(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....  :-(

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