You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Felix Röthenbacher <fe...@wyona.com> on 2005/12/05 15:53:08 UTC
fallback: and caching
Hi
I wonder how the fallback: protocol behaves when it comes
to caching? If several publications are in use at the same
time and resources are accessed with the fallback: protocol,
it seems that a cached resource is used instead of the resource
which applies to the current publication. Has anyone else
seen this behaviour?
Thanks for sharing your thoughts,
- Felix
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 19-01-2006 a las 13:39 +0100, Josias Thoeny escribió:
> On Thu, 2006-01-19 at 12:19 +0100, Thorsten Scherler wrote:
> > El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
> > >
> > > Thorsten Scherler wrote:
> > > >
> > ...
> > > > 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>
> > > >
> > ...
> > > Can you give an example how Lenya's templating hierarchy will look like
> > > implemented with the locationmap protocol?
> > >
> > > Thanks, Felix
> >
> > I will try but no guarantee that it is correct, since I could not find
> > any documentation about fallback in our official docu (hint, hint). ;-)
> >
> > <match pattern="fallback.**">
> > <select type="exists">
> > <location src="context://{lenya:pubId}/lenya/**"/>
> > <location src="context://{lenya:pubId}/**"/>
> > <location src="context://lenya/**"/>
> > <location src="context://**"/>
> > </select>
> > </match>
>
> When you use the locationmap source in the sitemap it would look like
> <map:transform src="lm://fallback.xslt/myxsl.xsl"/> ?
>
Yes, for example. Or just:
<map:transform src="lm://transform.xslt.myxsl"/>
That actually depends how you want to implement it.
> What I don't understand so far is how it solves the caching problem this
> thread is about.
> How does the locationmap tell cocoon that lm://fallback.xslt/myxsl.xsl
> is not the same as lm://fallback.xslt/myxsl.xsl if lenya:pubId is
> different?
Because the locationmap is a resolver which caches the lookups and is
aware that the pubid has changed. See the locationmap.xml from forrest
more details but the idea is that the pub specific match comes first.
...
<location src="context://{lenya:pubId}/lenya/**"/>
...
>
> Thanks for a clarification,
does it help? if not please keep on asking questions.
salu2
> Josias
>
> >
> > I guess that is the basic rule, right?
> >
> > The interesting is that a user can extend this default matches
> > (see other mail why and when).
> >
> > salu2
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Josias Thoeny <jo...@wyona.com>.
On Thu, 2006-01-19 at 12:19 +0100, Thorsten Scherler wrote:
> El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
> >
> > Thorsten Scherler wrote:
> > >
> ...
> > > 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>
> > >
> ...
> > Can you give an example how Lenya's templating hierarchy will look like
> > implemented with the locationmap protocol?
> >
> > Thanks, Felix
>
> I will try but no guarantee that it is correct, since I could not find
> any documentation about fallback in our official docu (hint, hint). ;-)
>
> <match pattern="fallback.**">
> <select type="exists">
> <location src="context://{lenya:pubId}/lenya/**"/>
> <location src="context://{lenya:pubId}/**"/>
> <location src="context://lenya/**"/>
> <location src="context://**"/>
> </select>
> </match>
When you use the locationmap source in the sitemap it would look like
<map:transform src="lm://fallback.xslt/myxsl.xsl"/> ?
What I don't understand so far is how it solves the caching problem this
thread is about.
How does the locationmap tell cocoon that lm://fallback.xslt/myxsl.xsl
is not the same as lm://fallback.xslt/myxsl.xsl if lenya:pubId is
different?
Thanks for a clarification,
Josias
>
> I guess that is the basic rule, right?
>
> The interesting is that a user can extend this default matches
> (see other mail why and when).
>
> salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 19-01-2006 a las 13:34 +0100, Andreas Hartmann escribió:
> Thorsten Scherler wrote:
> > El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
> >
> >>Thorsten Scherler wrote:
> >>
> > ...
> >
> >>>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>
> >>>
> > ...
> >
> >>Can you give an example how Lenya's templating hierarchy will look like
> >>implemented with the locationmap protocol?
> >>
> >>Thanks, Felix
> >
> >
> > I will try but no guarantee that it is correct, since I could not find
> > any documentation about fallback in our official docu (hint, hint). ;-)
>
> http://lenya.apache.org/1_4/reference/publication-templating/index.html#The+Concept+of+Publication+Templating
>
> BTW, there's apparently a mistake in the docs (see point 5).
Ok, thx for pointing this out. Actually I expected it in
http://lenya.apache.org/1_4/reference/protocols/index.html
Maybe it makes sense to either add a link there too or move the fallback
part there.
> It should read (I'll fix it):
>
> 1. context://lenya/pubs/my-pub/xslt/page2xhtml.xsl
> 2. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
> 3. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
> 4. ...
> 5. context://lenya/xslt/page2xhtml.xsl
>
ok, that will slightly change my example but the concept is the same.
>
> > <match pattern="fallback.**">
> > <select type="exists">
> > <location src="context://{lenya:pubId}/lenya/**"/>
>
> > <location src="context://{lenya:pubId}/**"/>
>
> No, this one has to be omitted.
>
> > <location src="context://lenya/**"/>
>
> > <location src="context://**"/>
>
> This one can be omitted as well.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
> El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
>
>>Thorsten Scherler wrote:
>>
> ...
>
>>>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>
>>>
> ...
>
>>Can you give an example how Lenya's templating hierarchy will look like
>>implemented with the locationmap protocol?
>>
>>Thanks, Felix
>
>
> I will try but no guarantee that it is correct, since I could not find
> any documentation about fallback in our official docu (hint, hint). ;-)
http://lenya.apache.org/1_4/reference/publication-templating/index.html#The+Concept+of+Publication+Templating
BTW, there's apparently a mistake in the docs (see point 5).
It should read (I'll fix it):
1. context://lenya/pubs/my-pub/xslt/page2xhtml.xsl
2. context://lenya/pubs/template(my-pub)/xslt/page2xhtml.xsl
3. context://lenya/pubs/template(template(my-pub))/xslt/page2xhtml.xsl
4. ...
5. context://lenya/xslt/page2xhtml.xsl
> <match pattern="fallback.**">
> <select type="exists">
> <location src="context://{lenya:pubId}/lenya/**"/>
> <location src="context://{lenya:pubId}/**"/>
No, this one has to be omitted.
> <location src="context://lenya/**"/>
> <location src="context://**"/>
This one can be omitted as well.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
[...]
> That highly depends on how we implement the locationmap in the core. The
> locationmap is configured via *one* locationmap, but within this map you
> can mount other locationsmap.
How does this behave from a performance-related point of view?
The TemplateFallbackSourceFactory basically checks a list of files for
existence. I could imagine that mounting locationmaps etc. could
significantly slow down the process. I understand that it is hard to tell
beforehand, but maybe you are familiar with this issue.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 19-01-2006 a las 13:29 +0100, Felix Röthenbacher escribió:
>
> Thorsten Scherler wrote:
> > El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
> >
> >>Thorsten Scherler wrote:
> >>
> > ...
> >
> >>>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>
> >>>
> > ...
> >
> >>Can you give an example how Lenya's templating hierarchy will look like
> >>implemented with the locationmap protocol?
> >>
> >>Thanks, Felix
> >
> >
> > I will try but no guarantee that it is correct, since I could not find
> > any documentation about fallback in our official docu (hint, hint). ;-)
> >
> > <match pattern="fallback.**">
> > <select type="exists">
> > <location src="context://{lenya:pubId}/lenya/**"/>
> > <location src="context://{lenya:pubId}/**"/>
> > <location src="context://lenya/**"/>
> > <location src="context://**"/>
> > </select>
> > </match>
>
> How do you implement a recursive dependency of publications like
>
> pubA <-- pubB <-- pubC <-- pubD
That highly depends on how we implement the locationmap in the core. The
locationmap is configured via *one* locationmap, but within this map you
can mount other locationsmap.
http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/locationmap.xml?view=markup
"...
<select>
<!-- Normally it is discouraged to use the cocoon:
protocol in the locationmap as this provides too much indirection.
However, this is a special case since it allows individual
projects to dynamically generate their locationmap. This is
required when content is being drawn from a remote repository
and we want the site structure to also come from that repository
-->
<mount src="cocoon://locationmap-project.xml"/>
</select>"
Something similar we can implement for lenya, still if you want to define in which order
the locationmap will mount the dependent pubs I reckon we need to write a custom action
(e.g. reuse the fallback:// logic).
>
> so that a resource not found in pubD is taken from one of its parents?
See the lm action I posted a link for.
> What are the prerequesites for configuring the templating hierarchy?
>
Do not understand what you mean, can you specify?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Felix Röthenbacher <fe...@wyona.com>.
Thorsten Scherler wrote:
> El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
>
>>Thorsten Scherler wrote:
>>
> ...
>
>>>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>
>>>
> ...
>
>>Can you give an example how Lenya's templating hierarchy will look like
>>implemented with the locationmap protocol?
>>
>>Thanks, Felix
>
>
> I will try but no guarantee that it is correct, since I could not find
> any documentation about fallback in our official docu (hint, hint). ;-)
>
> <match pattern="fallback.**">
> <select type="exists">
> <location src="context://{lenya:pubId}/lenya/**"/>
> <location src="context://{lenya:pubId}/**"/>
> <location src="context://lenya/**"/>
> <location src="context://**"/>
> </select>
> </match>
How do you implement a recursive dependency of publications like
pubA <-- pubB <-- pubC <-- pubD
so that a resource not found in pubD is taken from one of its parents?
What are the prerequesites for configuring the templating hierarchy?
- Felix
>
> I guess that is the basic rule, right?
>
> The interesting is that a user can extend this default matches
> (see other mail why and when).
>
> salu2
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 19-01-2006 a las 11:29 +0100, Felix Röthenbacher escribió:
>
> Thorsten Scherler wrote:
> >
...
> > 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>
> >
...
> Can you give an example how Lenya's templating hierarchy will look like
> implemented with the locationmap protocol?
>
> Thanks, Felix
I will try but no guarantee that it is correct, since I could not find
any documentation about fallback in our official docu (hint, hint). ;-)
<match pattern="fallback.**">
<select type="exists">
<location src="context://{lenya:pubId}/lenya/**"/>
<location src="context://{lenya:pubId}/**"/>
<location src="context://lenya/**"/>
<location src="context://**"/>
</select>
</match>
I guess that is the basic rule, right?
The interesting is that a user can extend this default matches
(see other mail why and when).
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Felix Röthenbacher <fe...@wyona.com>.
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: dev-unsubscribe@lenya.apache.org
>>For additional commands, e-mail: dev-help@lenya.apache.org
>>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 19-01-2006 a las 11:33 +0100, Andreas Hartmann escribió:
> Thorsten Scherler wrote:
>
> [...]
>
> > 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). ;-)
>
> Hmmmm ... I have to admit that I consider the location contract
> appropriate in this context. Configuring this would IMO be too
> much flexibility.
Why? The contract is *forcing* to extend the sitemap if you do want to
override the matching. see below when it becomes really bad.
>
> [...]
>
> > 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.
>
> Why would it not be sufficient?
>
If you use e.g. an external asset management system, which has its own
mapping for images. You will end up to either not use the fallback://
for that and implement customized matching in the sitemap. Then you
loose the fallback mechanism and need to implement your own one mostly
by adding source.exist actions into the sitemap till it becomes
unreadable. Or you use the fallback and copy all stuff to the
fallback:// conform structure. Either way far too much work when it
could be as easy as extending the locationmap with (e.g.):
<location src="http://assetManagementSystem/images/imageXY.jpg"/>
or
<location src="http://assetManagementSystem/images/{1}.{2}"/>
...and one thing what I really do not like is to duplicate resources or
doing extra work if I do not have to. *copyless* should be our
philosophy like in forrest.
>
> > 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.
>
> I still disagree. If I'm familiar with a publication, I'd expect the
> corresponding files in instances in the same locations.
>
Hmm, yeah *if* you are but not for the new user! I can tell the new
user:
Dude look in locationmap.xml and you find all the places where you put
stuff into. ...and I can tell you the same and both have the same
knowledge.
Like you stated your condition is that you have to fully understood a
pub, the locationmap is independent from the understanding of a pub
which makes it highly reusable in any cocoon based app besides a lenya
pub. I prefer to understand something globally workable then something
that is limited to one project.
>
> >>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. ;-)
>
> I agree to this statement. But I'm not convinced that we should allow
> to configure the locations.
¿Why not?, like stated above you always can look up the matching
mechanism.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
[...]
> 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). ;-)
Hmmmm ... I have to admit that I consider the location contract
appropriate in this context. Configuring this would IMO be too
much flexibility.
[...]
> 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.
Why would it not be sufficient?
> 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.
I still disagree. If I'm familiar with a publication, I'd expect the
corresponding files in instances in the same locations.
>>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. ;-)
I agree to this statement. But I'm not convinced that we should allow
to configure the locations.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
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. ;-)
salu2
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Andreas Hartmann <an...@apache.org>.
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. Why do we need more flexibility?
The major point to convince me would be to switch to an established
solution instead of using our own implementation.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 19-01-2006 a las 09:53 +0100, Felix Röthenbacher escribió:
>
> Thorsten Scherler wrote:
> > 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
> >
> >>From above linked document:
> > "A locationmap defines a mapping from requests to location strings.
> >
> > It was conceived to:
> >
> > * Provide a more powerful means for semantic linking.
> > * Enable Forrest with a standard configuration override mechanism.
> > * Decouple the conceptual source space used by Cocoon from the
> > concrete source space, so that a change in the concrete sources
> > does not impact on the sitemap.
> >
> > In other words, the locationmap enables content to be retrieved from a
> > location that is defined in a locationmap file (located at
> > PROJECT_HOME/src/documentation/content/locationmap.xml file. The
> > advantage of this is that the URL seen by the user need bear no relation
> > to the location of the source document, thus Forrest can separate the
> > client URL space from the source document URL space. Thus, using the
> > locationmap it is possible to pull together documents from many
> > different locations into a single uniform site."
> >
> > I would be happy to help seeting the locationmap up for lenya if you
> > need help, but IMO it is worth considering. The good news about it is
> > that lenya-trunk has a forrest.jar, so you can set it up nearly like
> > described in above link.
>
> It seems that the fallback: protocol does not work with caching, as the
> URL is used as the caching key (will re-assure on the Cocoon mailing
> list). The approach used by forrest seems to be based on input modules,
> but that's something different than a protocol. AFAIK then it will not
> be possible to use the source resolver for resolving fallback enabled
> sources.
>
ähm,
http://forrest.apache.org/docs_0_80/locationmap.html#sourceResolving
"As well as being able to use the locationmap as a parameter in the
sitemap, it is also possible to use it as a psuedo-protocol within
resources processed by Forrest. For example, you can use it to import an
XSL provided by one plugin within another plugin:
<xsl:import src="lm://OOo.transform.write.xdoc"/>"
and
El jue, 19-01-2006 a las 09:23 +0100, Thorsten Scherler escribió:
> A while ago I added a pseudo source protocol (lm://) to access the
> locationmap, so it is not anymore only an input module.
You could even still use the fallback protocol by defining the
locationmap source protocol (default set to lm://) as fallback://
Besides configurable caching is implemented in the locationmap resolver,
one thing less to worry. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Felix Röthenbacher <fe...@wyona.com>.
Thorsten Scherler wrote:
> 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
>
>>>From above linked document:
> "A locationmap defines a mapping from requests to location strings.
>
> It was conceived to:
>
> * Provide a more powerful means for semantic linking.
> * Enable Forrest with a standard configuration override mechanism.
> * Decouple the conceptual source space used by Cocoon from the
> concrete source space, so that a change in the concrete sources
> does not impact on the sitemap.
>
> In other words, the locationmap enables content to be retrieved from a
> location that is defined in a locationmap file (located at
> PROJECT_HOME/src/documentation/content/locationmap.xml file. The
> advantage of this is that the URL seen by the user need bear no relation
> to the location of the source document, thus Forrest can separate the
> client URL space from the source document URL space. Thus, using the
> locationmap it is possible to pull together documents from many
> different locations into a single uniform site."
>
> I would be happy to help seeting the locationmap up for lenya if you
> need help, but IMO it is worth considering. The good news about it is
> that lenya-trunk has a forrest.jar, so you can set it up nearly like
> described in above link.
It seems that the fallback: protocol does not work with caching, as the
URL is used as the caching key (will re-assure on the Cocoon mailing
list). The approach used by forrest seems to be based on input modules,
but that's something different than a protocol. AFAIK then it will not
be possible to use the source resolver for resolving fallback enabled
sources.
Best, Felix
>
> A while ago I added a pseudo source protocol (lm://) to access the
> locationmap, so it is not anymore only an input module.
>
> wdyt?
>
> salu2
>
>
>>Thanks,
>>--Doug
>>
>>Felix Röthenbacher wrote:
>>
>>>Hi
>>>
>>>I wonder how the fallback: protocol behaves when it comes
>>>to caching? If several publications are in use at the same
>>>time and resources are accessed with the fallback: protocol,
>>>it seems that a cached resource is used instead of the resource
>>>which applies to the current publication. Has anyone else
>>>seen this behaviour?
>>>
>>>Thanks for sharing your thoughts,
>>>
>>>- Felix
>>>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Thorsten Scherler <th...@apache.org>.
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
>>From above linked document:
"A locationmap defines a mapping from requests to location strings.
It was conceived to:
* Provide a more powerful means for semantic linking.
* Enable Forrest with a standard configuration override mechanism.
* Decouple the conceptual source space used by Cocoon from the
concrete source space, so that a change in the concrete sources
does not impact on the sitemap.
In other words, the locationmap enables content to be retrieved from a
location that is defined in a locationmap file (located at
PROJECT_HOME/src/documentation/content/locationmap.xml file. The
advantage of this is that the URL seen by the user need bear no relation
to the location of the source document, thus Forrest can separate the
client URL space from the source document URL space. Thus, using the
locationmap it is possible to pull together documents from many
different locations into a single uniform site."
I would be happy to help seeting the locationmap up for lenya if you
need help, but IMO it is worth considering. The good news about it is
that lenya-trunk has a forrest.jar, so you can set it up nearly like
described in above link.
A while ago I added a pseudo source protocol (lm://) to access the
locationmap, so it is not anymore only an input module.
wdyt?
salu2
> Thanks,
> --Doug
>
> Felix Röthenbacher wrote:
> > Hi
> >
> > I wonder how the fallback: protocol behaves when it comes
> > to caching? If several publications are in use at the same
> > time and resources are accessed with the fallback: protocol,
> > it seems that a cached resource is used instead of the resource
> > which applies to the current publication. Has anyone else
> > seen this behaviour?
> >
> > Thanks for sharing your thoughts,
> >
> > - Felix
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Doug Chestnut <dh...@virginia.edu>.
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?
Thanks,
--Doug
Felix Röthenbacher wrote:
> Hi
>
> I wonder how the fallback: protocol behaves when it comes
> to caching? If several publications are in use at the same
> time and resources are accessed with the fallback: protocol,
> it seems that a cached resource is used instead of the resource
> which applies to the current publication. Has anyone else
> seen this behaviour?
>
> Thanks for sharing your thoughts,
>
> - Felix
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: fallback: and caching
Posted by Doug Chestnut <dh...@virginia.edu>.
Hi Felix,
I was only experiencing this problem with xsl:include="fallback://...
ex:
pub1 and pub2 both use default for a template
-pub1 has an xslt dir with its own page2xhtml.xsl (all other xsl falls
back to default/xslt/)
-pub2 doesn't have an xslt dir
-request comes in for /pub1/authoring/xhtmlres.html
-at some point the sitemap does a transform using
default/xslt/page2xhtml-xhtml.xsl
-all that is in the xsl is fallback://xslt/page2xhtml.xsl
-pub1/xslt/page2xhtml.xsl is used
-expected result
-request comes in for /pub2/authoring/xhtmlres.html
-at some point the sitemap does a transform using
default/xslt/page2xhtml-xhtml.xsl
-all that is in the xsl is fallback://xslt/page2xhtml.xsl
-***pub1/xslt/page2xhtml.xsl is used***
-unexpected result
Setting the XSLT Processor's use-store param to false seems to fix the
problem for me. Don't know if performance will take a big hit though.
HTH
--Doug
Felix Röthenbacher wrote:
> Hi
>
> I wonder how the fallback: protocol behaves when it comes
> to caching? If several publications are in use at the same
> time and resources are accessed with the fallback: protocol,
> it seems that a cached resource is used instead of the resource
> which applies to the current publication. Has anyone else
> seen this behaviour?
>
> Thanks for sharing your thoughts,
>
> - Felix
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org