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
