forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: (Re: Q: Images-Cascade in Resources.xmap)
Date Thu, 20 Apr 2006 13:04:16 GMT
Ferdinand Soethe wrote:
> 
> 
> 
> 
> 
> 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?

What I meant was, it is a requirement for a version 1, not that we need 
to wait till then. The sooner it gets done the better. But it is not a 
priority for me, personally, at this time.

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

By documented I mean in the upgrade instructions, not in the core 
documentation. For example: 
http://forrest.apache.org/docs_0_70/upgrading_07.html

In such a document we would say that users need to do one of three things:

1) update directory structures to reflect the recommended structure
2) copy the legacy locationmap into their project
3) build a custom locationmap to ensure their resources are located 
correctly


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

If we clearly mark it as deprecated/legacy we shouldn't have that 
problem. I would hate to see us just abandon users by not providing the 
locationmap. It is only a case of copying what we currently have and 
adding a note into the upgrade instructions. Not much work at all.

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

Hmmmm.. not specifically. The properties come from an input module in 
Cocoon, so I guess 
http://cocoon.apache.org/2.1/userdocs/concepts/modules.html is a good 
starting point.

Ross

Mime
View raw message