Ferdinand Soethe wrote:
Ross Gardler wrote:
Am I helping or confusing?
Helping (me), thanks.
Still, I'm looking at this and wonder.
It seems to me like these cascades create a behavior that is very hard to
predict by the user. And probably - unless you really study that
sitemap - for many developers as well.
The official documented approaches are predictable. However, looking at
the code is confusing. This is because we are still supporting all the
legacy ways of doing things.
In my own mind I envision a version 1.0 of Forrest that removes all this
potential confusion. It is one reason why I wanted the locationmap in
use. We can deprecate all the old legacy locations and place them in a
special "deprecated-locationmap". Then when we write the upgrade
instructions for version 0.x to 1.0 we can say "you should restructure
your source files to conform to the standard Forrest structure, or you
can create a custom locationmap to support your own structure, or you
can use the deprecated-locationmap to just have things work"
The deprecated locaitonmap could either be a FAQ with code snippets or a
complete locationmap (or both).
However, I have not proposed this yet we have enough unfinished jobs at
present but...
Why not define these patterns and put them as settings into Forrest
properties. Use switches to support these patterns in the sitemap so
that each usage-patterns has just one predictable behavior.
-1 to doing it in the sitemap. That is what the locationmap is for.
Adding switches and properties just makes the config files really
confusing and adds loads of processing to each request. However, the
locationmap approach will actually make things easier to read and makes
processing more efficient (less locations to check).
Ross
