Thorsten Scherler wrote:
El jue, 19-01-2006 a las 09:46 +0100, Andreas Hartmann escribió:
Thorsten Scherler schrieb:
El mié, 18-01-2006 a las 21:17 -0500, Doug Chestnut escribió:
Hi Felix,
I have just started to see this problem as well. A request for
fallback://xslt/page2xhtml.xsl seems to get cached, and is used by other
publications. Odd that I haven't seen it till now. Have you found a
solution?
I have not a simple solution but maybe it makes sense to use the
locationmap http://forrest.apache.org/docs_0_80/locationmap.html instead
of the fallback.
The argumentation why is that you can
a) do the same as with the fallback source
b) do much more and you are much more flexible in doing it
As I understand it, the location map provides explicit mapping of
resources. Fallback provides an implicit mapping, which IMO is
sufficient for publication templating.
The locationmap provides a matching mechanism that is fully configurable
were the fallback:// is expecting the files in a fixed defined path
(e.g. lenya/xslt/some.xsl) forcing the dev/user to imitate/adopt this
structure. Meaning *lenya* defines the location (I hate to be forced to
do something). ;-)
Were else the locationmap let the *user* define the location and the
"to-be-used" fallbacks:
<match pattern="tabs.xml">
<select type="exists">
<location src="{project:content.xdocs}tabs1.xml"/>
<location src="{project:content.xdocs}tabs2.xml"/>
</select>
</match>
Will first look for {project:content.xdocs}tabs1.xml and if it cannot be found
it will look for {project:content.xdocs}tabs2.xml. The user is always in control
which locations to be mapped.
Now to why I think
"Fallback provides an implicit mapping, which IMO is
sufficient for publication templating. "
is not true. Imagine images or design resources in general in a
multi-pub environment, here I do want to have full control over the
mapping.
Further I activated actions in the locationmap when I wrote an implicit
mapping action
http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer/src/java/org/apache/forrest/structurer/acting/RecursiveDirectoryTraversalAction.java?rev=320710&view=markup
This is a fallback mechanism that we have in the dispatcher to match
view definition files.
Why do we need more flexibility?
To keep the site structurer open and not forcing to use the lenya
default one. IMO this adds to the entry barrier understanding lenya.
When I started I never really understand why some files *have to* go
into dir a and others in dir b. Let the user/dev decide this mappings.
The major point to convince me would be to switch to an established
solution instead of using our own implementation.
That is another point, what do we gain with the fallback:// what the
locationmap cannot gives us? If the answer is: nothing. Then I say we
are having the "luxury" of duplicate code, which is bad for maintenance.
Our committer base is still quite small and should focus on stuff that
we do not duplicate. Let forrest worry about locationmap maintenance and
if we find a bug we can fix it in their rep right away since we all have
write access there. I say pretty good deal. ;-)
Can you give an example how Lenya's templating hierarchy will look like
implemented with the locationmap protocol?
Thanks, Felix
salu2
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Felix Röthenbacher [EMAIL PROTECTED]
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
