forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: (Re: Q: Images-Cascade in Resources.xmap)
Date Thu, 20 Apr 2006 10:16:06 GMT






Ross Gardler wrote:


>> The way I read that, the legacy support for images in a path below
>> xdocs that has images in it is always supported and actually takes
>> precedence over the currently documented solution.

> Oh. I had assumed that the precedence order is what appears in the docs.
> As you say, it *should* be.

Well and even if it was, in case of a user error (image not there)
we'd still have the fallback to the undocumented solution rather then
an error (Ok, a bit unlikely may be ...)


>> That was actually the second solution I had in mind. But it doesn't
>> really work well with different usage patterns because we would have
>> to support a number of different locationsmap-alternatives
>> permanently. That seems not only cumbersome but also very error prone.

> Why would we support numerous locationmaps? Wouldn't we have the one 
> "official" locationmap, this would implement the recommended file 
> structure. That's it.

Actually that would be my preference. But then, why wait for version 1
to do that. Why not clean up as we go to each next version?

> We would need to document how to support legacy 
> locations, but that would be all wouldn't it?

So far I understood Forrest policy to maintain backward compatibility
as far as possible.

Problem I see is that the documented legacy support will either have
to be maintained or will eventually break as we develop new versions.

But frankly I'd much rather go your way and do away with the old
stuff. Perhaps not even offer a locationsmap for the previous way
since that creates a false impression that we will support it in the
future.


> Well, as Thorsten said, we could use forrest.properties.xml to define 
> the entries in the locationmap. This way power users still get to do it
> my way and basic users get to edit a simple properties file. But...

Sounds good to me.

>>>and adds loads of processing to each request.
>> 
>> 
>> Why is that?

> Because you have to resolve the property each time that part of the 
> sitemap is processed, even if the document is in the cache. This is 
> because you need the properties to test the cache validity.

Can you point me to something to read up on that? I'd really like to
understand that better.

Thanks

--
Ferdinand Soethe


Mime
View raw message