locationmap mounting behavior

[Tim Williams <wi...@gmail.com>]

Is it enough to have locationmaps mounted as a sibling to components
and locator? or, should we support mounting inside match statements as
well?  I think this first way supports our Forrest internal needs of
project-level locations preferenced to app-level locations, I just
don't know that I see us needing selective match-based mounting right
now?  Anyone?
Thanks,
--tim

<locationmap xmlns="http://apache.org/forrest/locationmap/1.0">
  <components>
    ..matchers and selector stuff...
  </components>

  <mount src="{project:content}locationmap2.xml"/>
  
  <locator>
    <match pattern="rewriteDemo/**">
       <location src="http://www.burrokeet.org/{1}.xml" />
    </match> 
  </locator>
</locationmap>

Re: locationmap mounting behavior

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
> On 8/14/05, Ross Gardler <rg...@apache.org> wrote:
> 
>>Tim Williams wrote:
>>

...

>>There isn't an immediate need for the latter, but there is a need for
>>the former, so why the question? Do you have another solution for the
>>forrest locationmap in mind?
> 
> 
> nope, just wanted to know which nodes need to allow child "mount"
> nodes.  I just committed the first capability described above and if
> it turns out "match" nodes also can have child "mount"'s, then we can
> do that later.

+1

> i guess now i can look into removing the interim sitemap-based 'exists
> selector' solution to locationmap mounting.

+1

>  i'm going to have to
> think through the plugin mounting though, if it works the same as
> project-level mounting then it should work fine.

Lets not worry about the plugin mounting stuff for now. There is no use 
case yet, we'll worry about it when someone comes up with one.

Ross

Re: locationmap mounting behavior

[Tim Williams <wi...@gmail.com>]

On 8/14/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > Is it enough to have locationmaps mounted as a sibling to components
> > and locator? or, should we support mounting inside match statements as
> > well?  I think this first way supports our Forrest internal needs of
> > project-level locations preferenced to app-level locations, I just
> > don't know that I see us needing selective match-based mounting right
> > now?
> 
> We need it, as you say, to enable a project locationmap to override the
> forrest locationmap. It is also feasible that plugins will want to
> provide a locationmap and this will need to be mounted in the same way
> that project xmaps are mounted.
> 
> There isn't an immediate need for the latter, but there is a need for
> the former, so why the question? Do you have another solution for the
> forrest locationmap in mind?

nope, just wanted to know which nodes need to allow child "mount"
nodes.  I just committed the first capability described above and if
it turns out "match" nodes also can have child "mount"'s, then we can
do that later.

i guess now i can look into removing the interim sitemap-based 'exists
selector' solution to locationmap mounting.  i'm going to have to
think through the plugin mounting though, if it works the same as
project-level mounting then it should work fine.
--tim

Re: locationmap mounting behavior

[Ross Gardler <rg...@apache.org>]

Tim Williams wrote:
> Is it enough to have locationmaps mounted as a sibling to components
> and locator? or, should we support mounting inside match statements as
> well?  I think this first way supports our Forrest internal needs of
> project-level locations preferenced to app-level locations, I just
> don't know that I see us needing selective match-based mounting right
> now?

We need it, as you say, to enable a project locationmap to override the 
forrest locationmap. It is also feasible that plugins will want to 
provide a locationmap and this will need to be mounted in the same way 
that project xmaps are mounted.

There isn't an immediate need for the latter, but there is a need for 
the former, so why the question? Do you have another solution for the 
forrest locationmap in mind?

Ross