Re: biting the tomcat bullet and xmlc

Hi David,

At 09:35 PM 9/11/2003 -0700, you wrote:
>Hi all,
>I'm trying to figure out how to develop html pages in
>an xmlc & tomcat environment.  Are there any suggested
>tomcat file hierarchies for placing xmlc-ready html
>files and the generated xmlc class files?

As David Li pointed out, there is an Tomcat example app that shipped with 
XMLC-2.2.  Check that out for examples.

>With the enhydra tree, it was a cinch to use
>Dreamweaver to evolve the html pages and just build
>the app in place. It was all under
>./presentation/resources.  With tomcat, I'm not sure
>how to handle the relative URLs (e.g., how the html
>page references gif images).

In a basic WAR structure, all static files are under a single 
directory.  If you make everything relative to this directory, then you are 
golden.  If you aren't sure exactly what path the servlet will be serving 
up the XMLC-generated page from, then you might have to do something like 
pre-pending the context path.  For instance, if you are going to be 
deploying to the  context "/Myapp", you can pre-pend "/MyApp/" to all image 
paths using an XMLC -urlmapping.  Otherwise, you can do this at runtime 
using XMLC or use a servlet filter to re-write the image paths before just 
before the page is served up.

In Barracuda, we have something called a Resource Gateway servlet that 
serves static content up off the classpath so that the resources can be 
stored in a .jar file and be guaranteed to work no matter what path the 
servlet used.  We use this for reusable apps like the BConfig app where all 
you have to do is drop the barracuda-config.jar into your app and not have 
to worry about moving over static content (images, css, javascript, etc...) 
in order for it to work.  It is all included in the jar file.

>     Do you use the
>urlmapping option to rename the paths from where
>dreamweaver believes the resources are to what tomcat
>wants them?

Where does DreamWeaver believe the resources are?  All paths must be 
relative in order for DreamWeaver to deal with local resources.  As I 
stated above, if you keep everything relative and serve up the page from 
paths relative to the original resource hierarchy, you should have no problem.

>Hope my question makes some sense.  Would love your
>suggestions.

It makes sense.  However, have you run into a problem that you can, 
concretely, describe to me?  That might make it easier to solve. There are 
lots of things that can go wrong for lots of reasons.  Narrowing down the 
problem scope would probably help in coming up with a solution to your 
specific issue.

Jake

>David
>_______________________________________________
>XMLC mailing list
>[email protected]
>http://www.enhydra.org/mailman/listinfo.cgi/xmlc