> What happens it your www.site1.com decides to
> deploy the application as www.site1.com/app1...? The context path is set
in the
> deployment descriptor, not in the code. You really should make your code
> independent of the deployment descriptor even if it just happens to be
that your
> current deployment descriptors match your code.
It is an upfront decision to go with a "root-relative" site (and site
promotion process), like going with java as opposed to the many other
technologies (what would happen if your site decides to use C on the
backend?). It is something that needs to be agreed upon early for a large,
multi-faceted site.
Our sites are mostly built with XSL/XML ( perhaps 1 to 4 XSL guys working
on a site at a time) and currently they are mostly separate from any backend
processes (maybe 75% pregenerated to html). If I were to implement what you
are talking about:
(- there would need to be some way to dynamically generate the previously
pre-generated pages,
or
- pre-generate on and with each particular machine's context, )
and
- pass the approriate variable parameters to the XSL
This could defeat the promotion process. Currently we are assured that what
is seen on qa is what will be on live. The only variable in the promotion
process between qa and live is the cost/type of machine.
Since there are several resources (human and not) involved it is better to
set the site structure early. It really clears things up for all invloved
and allows for a clean separation from others.
