You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2005/08/19 15:45:13 UTC
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/stylesheets/
whiteboard/plugi...)
On Fri, 2005-08-19 at 09:52 +0100, Ross Gardler wrote:
> thorsten@apache.org wrote:
> > Author: thorsten
> > Date: Thu Aug 18 17:44:00 2005
> > New Revision: 233401
> >
>
> ...
>
> > Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/java/org/apache/forrest/plugin/internal/view/acting/FallbackResolverAction.java
>
> Does this fallback resolver work with the locationmap?
>
What do you mean?
> What does this do that the locationmap does not do?
>
It computes a dynamic path for fallback file.
+ public void computeResponseURI(SourceResolver resolver, String uri)
{
+ if (this.resourceExist(resolver, uri)) {
+ fallbackHelper.setResponseURI(uri);
+ } else {
+ if (fallbackHelper.getRest().lastIndexOf("/") > -1) {
+
fallbackHelper.setRest(fallbackHelper.getRest().substring(0,
+ fallbackHelper.getRest().lastIndexOf("/")));
+ uri = fallbackHelper.getProjectDir() +
fallbackHelper.getRest()
+ + "/" + fallbackHelper.getProjectFallback()
+ + fallbackHelper.getProjectExtension();
+ this.computeResponseURI(resolver,uri);
+ }else{
+ uri = fallbackHelper.getProjectDir()
+ +fallbackHelper.getProjectFallback()
+ +fallbackHelper.getProjectExtension();
+ if (this.resourceExist(resolver, uri)) {
+ fallbackHelper.setResponseURI(uri);
+ }
+ }
+ }
+ }
The locationmap needs to be defined and edited. All fallbacks that you
want to use, you have to define before, not very suitable for a high
dynamic environment like views.
The action reads a location (uri) and scans it whether a file exist. If
not it will scan for any project specific fallbacks that may exist (see
above). After this it scans further for default fallbacks (see
FallbackResolverAction.java). Actually in above code we now can easily
instance the SourceTypeAction [1] and implement "content aware
views" (FOR-621).
Can the loactionmap help me with all that?
salu2
[1] http://forrest.apache.org/docs_0_80/cap.html
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.inte
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
>On Wed, 2005-08-24 at 09:54 -0400, Tim Williams wrote:
>...
>
>
>>>>>If I understand you the functionality is the same, and appears to be
>>>>>more flexible in the locationmap (although I'm in a noisy net cafe and
>>>>>cannot concentrate fully). Can we stick to just one solution?
>>>>>
>>>>>
>>>>Yes, why not, but the locationmap is not a solution to my problem right
>>>>now, that is how I personally see it. If you can provide an example how
>>>>the lm is solving the fallback mechanism for views without defining all
>>>>the fallbacks in the lm then I will be more then happy to use it.
>>>>
>>>>
>>>Do you meand "the user defining all the fallbacks"? in the sense of
>>>Forrest defining some locations and the user (optionally) defining some.
>>>If so I address this above, otherwise I don't understand your point,
>>>please expand.
>>>
>>>
>>Here's what I think I understand of the problem. His fallbacks work
>>like this in order:
>>
>>1. File-based
>>2. Directory-based
>>3. Parent-directory based (recursively)
>>4. Theme based
>>5. Application Default
>>
>>
>>
>
>Yes, that is right. I will add a doctype specific fallback as well the
>next days which I am right now developing.
>
>
>
>>Ok, maybe not exactly, but it gives the general idea. Anyway,
>>locationmaps can solve all of those except, I think, #3. We have no
>>ability to do a "..\" up the directory tree until we find it. We can't
>>dissect the "matcher" result enough to do it either if that makes any
>>sense. I think either way we're probably going to need some java code
>>to do this stuff.
>>
>>
>
>exactly!!! Thanks for writing this down so spot on, Tim. :)
>
>
Yes, thanks Tim, I now understand.
>>One might argue that it should be a new selector I
>>suppose -- in which case, I'd say that it should only handle the
>>generic directory traversing part and not forrest-specific defaults.
>>In other words, implement the recursive directory traversal with a new
>>selector and use the built-in capability of the lm to do the rest --
>>that'd give us a more generic directory traversing selector.
>>
>>
>
>Agreed (partly). ;-) The design of the action is quite generic already
>and could be reused in any cocoon based app that needs fallbacks, anyway
>the combination like you suggest seems to be very nice.
>
>
+1
>Can a selector in the lm provide a map? Can I use:
><traversal>
> <location src="{calculatedValue}"/>
></traversal>
>
>If the <traversal> selector returns null then the child will be ignored,
>otherwise it will use the {calculatedValue} that have been placed in the
>returning map of the selector. Is that possible?
>
>
As I understand it, the LM can use any matchers or selectors available
within Cocoon. So I guess that means the answer is yes, however, Tim is
clearly more tuned in to this stuff so I'll leave it to you guys.
Perhaps we should raise an issue to do this work at some point (seems to
me like this is an ideal thing for Thorsten and Tim to tackle on a
Forrest Tuesday if they both happen to be online at the same time).
Ross
Re: Fwd: Fallback resolver Vs. Locationmap (was Re: svn commit:
r233401 - in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/
site-author/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/
whiteboard/plugins/org.apache.forrest.plugin.int
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-08-26 at 08:41 -0400, Tim Williams wrote:
> > > Here's what I think I understand of the problem. His fallbacks work
> > > like this in order:
> > >
> > > 1. File-based
> > > 2. Directory-based
> > > 3. Parent-directory based (recursively)
> > > 4. Theme based
> > > 5. Application Default
> > >
> >
> > Yes, that is right. I will add a doctype specific fallback as well the
> > next days which I am right now developing.
> >
That is blocked by the select issue with the locationmap right now.
> > > Ok, maybe not exactly, but it gives the general idea. Anyway,
> > > locationmaps can solve all of those except, I think, #3. We have no
> > > ability to do a "..\" up the directory tree until we find it. We can't
> > > dissect the "matcher" result enough to do it either if that makes any
> > > sense. I think either way we're probably going to need some java code
> > > to do this stuff.
> >
> > exactly!!! Thanks for writing this down so spot on, Tim. :)
> >
> > > One might argue that it should be a new selector I
> > > suppose -- in which case, I'd say that it should only handle the
> > > generic directory traversing part and not forrest-specific defaults.
> > > In other words, implement the recursive directory traversal with a new
> > > selector and use the built-in capability of the lm to do the rest --
> > > that'd give us a more generic directory traversing selector.
> >
I wrote an action for that and enabled actions in the lm. I have
problems right now to make the select work but here is the lm snippet
which will replace the fallback resolver.
<match pattern="views/**">
<select type="exists">
<!-- File-based -->
<location src="{1}{project:theme-ext}" />
<act type="sourcetype" src="{1}.xml">
<!-- Sourcetype-based -->
<location
src="{project:theme-sourcetypeDir}{sourcetype}{project:theme-ext}" />
</act>
<act type="RecursiveDirectoryTraversalAction">
<parameter value="{1}" name="request"/>
<parameter value="{project:theme}" name="projectFallback"/>
<parameter value="{project:theme-ext}" name="projectExtension"/>
<parameter value="{project:content.xdocs}" name="projectDir"/>
<!-- Directory-based / Parent-directory based (recursively) -->
<location src="{uri}" />
</act>
<!-- Theme based -->
<location
src="{defaults:view-themes}/{project:theme}{project:theme-ext}" />
</select>
<!-- Application Default -->
<location
src="{defaults:view-themes}/{defaults:theme}{defaults:theme-ext}" />
</match>
Thanks to you and Ross for pointing out and finding this solution and
especially for clarifying the problematic. :)
As soon as the select in lm is working I can apply it.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [locationmap] How to activate actions in the locationmap
Posted by Thorsten Scherler <th...@apache.org>.
On Sat, 2005-08-27 at 22:53 +0200, Thorsten Scherler wrote:
> > I needed do change some classes to allow actions in the lm to be
> > matched:
> > ? java/org/apache/forrest/locationmap/lm/ActNode.java
> > M java/org/apache/forrest/locationmap/lm/MatchNode.java
> > M java/org/apache/forrest/locationmap/lm/SelectNode.java
> > M java/org/apache/forrest/locationmap/lm/LocationMap.java
> > M java/org/apache/forrest/locationmap/lm/LocatorNode.java
> >
> > The step where I need some help with in ActNode.java is how do I get:
> > public String locate(Map objectModel, InvokeContext context) throws
> > Exception {
> > Parameters parameters = resolveParameters(context,objectModel);
> > Map substitutions = m_action.act(redirector, resolver, objectModel,
> > source, parameters);
> > ...
> > }
> > working.
>
> BTW should I check that in regardless it is <act/> is not working?
> Everything else seems to work fine?
>
Parameters parameters = resolveParameters(context,objectModel);
Redirector redirector = context.getRedirector();
String source = "";
Still need to test.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [locationmap] How to activate actions in the locationmap
Posted by Thorsten Scherler <th...@apache.org>.
> I needed do change some classes to allow actions in the lm to be
> matched:
> ? java/org/apache/forrest/locationmap/lm/ActNode.java
> M java/org/apache/forrest/locationmap/lm/MatchNode.java
> M java/org/apache/forrest/locationmap/lm/SelectNode.java
> M java/org/apache/forrest/locationmap/lm/LocationMap.java
> M java/org/apache/forrest/locationmap/lm/LocatorNode.java
>
> The step where I need some help with in ActNode.java is how do I get:
> public String locate(Map objectModel, InvokeContext context) throws
> Exception {
> Parameters parameters = resolveParameters(context,objectModel);
> Map substitutions = m_action.act(redirector, resolver, objectModel,
> source, parameters);
> ...
> }
> working.
BTW should I check that in regardless it is <act/> is not working?
Everything else seems to work fine?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [locationmap] How to activate actions in the locationmap
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-08-28 at 18:53 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > --closed--
> >
> > I activated actions in the locationmap successfully. :) I will commit
> > asap.
>
> Cool stuff, great to see we (well, you at the moment) are actioning
> Davids request for us to broaden our perspective from our "pet"
> projects. I'm still playing with views, but you will see more commits
> from me soon since I am using it in production now.
>
> Ross
I am looking forward to see your code. ;-)
BTW there is a bug in the ActNode. It is not reading <act type="..."
src="notReaded"/> the @src attribute. I found out in trying to use the
sourcetype action in the lm.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [locationmap] How to activate actions in the locationmap
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> --closed--
>
> I activated actions in the locationmap successfully. :) I will commit
> asap.
Cool stuff, great to see we (well, you at the moment) are actioning
Davids request for us to broaden our perspective from our "pet"
projects. I'm still playing with views, but you will see more commits
from me soon since I am using it in production now.
Ross
Re: [locationmap] How to activate actions in the locationmap
Posted by Thorsten Scherler <th...@apache.org>.
--closed--
I activated actions in the locationmap successfully. :) I will commit
asap.
On Sat, 2005-08-27 at 22:17 +0200, Thorsten Scherler wrote:
> On Fri, 2005-08-26 at 08:41 -0400, Tim Williams wrote:
>
> > > Can a selector in the lm provide a map? Can I use:
> > > <traversal>
> > > <location src="{calculatedValue}"/>
> > > </traversal>
> > >
> > > If the <traversal> selector returns null then the child will be ignored,
> > > otherwise it will use the {calculatedValue} that have been placed in the
> > > returning map of the selector. Is that possible?
> >
> > I missed this reply. If I understand the question, the answer is kind
> > of. All null-returning locations would be ignored except the last one
> > which would, not surprisingly, actually return null, meaning your
> > example above would also return null. If this is done in the context
> > of a parent selector, then maybe it would get ignored -- I'd have to
> > check.
> >
> > I'll admit that I didn't fully cook the [new traversal selector] idea
> > in my head before my fingers started typing it;) I think this one
> > deserves more study and should be filed as a JIRA issue.
> >
>
> I just looked into
> package org.apache.cocoon.selection;
> public interface Selector extends Component {
>
> String ROLE = Selector.class.getName();
> /**
> * Selectors test pattern against some objects in a <code>Map</code>
> * model and signals success with the returned boolean value
> * @param expression The expression to test.
> * @param objectModel The <code>Map</code> containing object of the
> * calling environment which may be used
> * to select values to test the expression.
> * @param parameters The sitemap parameters, as specified by
> <parameter/> tags.
> * @return boolean Signals successfull test.
> */
> boolean select (String expression, Map objectModel, Parameters
> parameters);
> }
>
> What I had in mind is not possible with a selector. That leads us to the
> question whether it is possible to use actions in lm. The answer was not
> out of the box how I found out. ;-)
>
> I wrote a new action RecursiveDirectoryTraversalAction.java that only
> contains the recursive part of the fallbackResolverAction. I tested it
> on the sitemap and that worked just fine.
>
> Now I extend my project lm like this:
> ...
> <components>
> ...
> <actions default="RecursiveDirectoryTraversalAction">
> <action name="RecursiveDirectoryTraversalAction"
> src="org.apache.forrest.plugin.internal.view.acting.RecursiveDirectoryTraversalAction"/>
> </actions>
> ...
> </components>
> <locator>
> <match pattern="views/**">
> <act type="RecursiveDirectoryTraversalAction">
> <parameter value="{1}" name="request"/>
> <parameter value="{project:theme}" name="projectFallback"/>
> <parameter value="{project:theme-ext}" name="projectExtension"/>
> <parameter value="{project:content.xdocs}" name="projectDir"/>
> <location src="{uri}" />
> </act>
> <location
> src="{defaults:view-themes}/{defaults:theme}{defaults:theme-ext}"
> />
> </match>
> </locator>
> ...
>
> I needed do change some classes to allow actions in the lm to be
> matched:
> ? java/org/apache/forrest/locationmap/lm/ActNode.java
> M java/org/apache/forrest/locationmap/lm/MatchNode.java
> M java/org/apache/forrest/locationmap/lm/SelectNode.java
> M java/org/apache/forrest/locationmap/lm/LocationMap.java
> M java/org/apache/forrest/locationmap/lm/LocatorNode.java
>
> The step where I need some help with in ActNode.java is how do I get:
> public String locate(Map objectModel, InvokeContext context) throws
> Exception {
> Parameters parameters = resolveParameters(context,objectModel);
> Map substitutions = m_action.act(redirector, resolver, objectModel,
> source, parameters);
> ...
> }
> working.
>
> Where can I get the redirector, resolver and the source that I need to
> parse to the action? Any tips welcome.
>
> TIA
>
> salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
[locationmap] How to activate actions in the locationmap
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-08-26 at 08:41 -0400, Tim Williams wrote:
> > Can a selector in the lm provide a map? Can I use:
> > <traversal>
> > <location src="{calculatedValue}"/>
> > </traversal>
> >
> > If the <traversal> selector returns null then the child will be ignored,
> > otherwise it will use the {calculatedValue} that have been placed in the
> > returning map of the selector. Is that possible?
>
> I missed this reply. If I understand the question, the answer is kind
> of. All null-returning locations would be ignored except the last one
> which would, not surprisingly, actually return null, meaning your
> example above would also return null. If this is done in the context
> of a parent selector, then maybe it would get ignored -- I'd have to
> check.
>
> I'll admit that I didn't fully cook the [new traversal selector] idea
> in my head before my fingers started typing it;) I think this one
> deserves more study and should be filed as a JIRA issue.
>
I just looked into
package org.apache.cocoon.selection;
public interface Selector extends Component {
String ROLE = Selector.class.getName();
/**
* Selectors test pattern against some objects in a <code>Map</code>
* model and signals success with the returned boolean value
* @param expression The expression to test.
* @param objectModel The <code>Map</code> containing object of the
* calling environment which may be used
* to select values to test the expression.
* @param parameters The sitemap parameters, as specified by
<parameter/> tags.
* @return boolean Signals successfull test.
*/
boolean select (String expression, Map objectModel, Parameters
parameters);
}
What I had in mind is not possible with a selector. That leads us to the
question whether it is possible to use actions in lm. The answer was not
out of the box how I found out. ;-)
I wrote a new action RecursiveDirectoryTraversalAction.java that only
contains the recursive part of the fallbackResolverAction. I tested it
on the sitemap and that worked just fine.
Now I extend my project lm like this:
...
<components>
...
<actions default="RecursiveDirectoryTraversalAction">
<action name="RecursiveDirectoryTraversalAction"
src="org.apache.forrest.plugin.internal.view.acting.RecursiveDirectoryTraversalAction"/>
</actions>
...
</components>
<locator>
<match pattern="views/**">
<act type="RecursiveDirectoryTraversalAction">
<parameter value="{1}" name="request"/>
<parameter value="{project:theme}" name="projectFallback"/>
<parameter value="{project:theme-ext}" name="projectExtension"/>
<parameter value="{project:content.xdocs}" name="projectDir"/>
<location src="{uri}" />
</act>
<location
src="{defaults:view-themes}/{defaults:theme}{defaults:theme-ext}"
/>
</match>
</locator>
...
I needed do change some classes to allow actions in the lm to be
matched:
? java/org/apache/forrest/locationmap/lm/ActNode.java
M java/org/apache/forrest/locationmap/lm/MatchNode.java
M java/org/apache/forrest/locationmap/lm/SelectNode.java
M java/org/apache/forrest/locationmap/lm/LocationMap.java
M java/org/apache/forrest/locationmap/lm/LocatorNode.java
The step where I need some help with in ActNode.java is how do I get:
public String locate(Map objectModel, InvokeContext context) throws
Exception {
Parameters parameters = resolveParameters(context,objectModel);
Map substitutions = m_action.act(redirector, resolver, objectModel,
source, parameters);
...
}
working.
Where can I get the redirector, resolver and the source that I need to
parse to the action? Any tips welcome.
TIA
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Fwd: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401 - in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.int
Posted by Tim Williams <wi...@gmail.com>.
Not sure why that happened but my reply went personal instead of the list...
--tim
On 8/24/05, Thorsten Scherler <th...@apache.org> wrote:
> On Wed, 2005-08-24 at 09:54 -0400, Tim Williams wrote:
> ...
> > > >>If I understand you the functionality is the same, and appears to be
> > > >>more flexible in the locationmap (although I'm in a noisy net cafe and
> > > >>cannot concentrate fully). Can we stick to just one solution?
> > > >
> > > >
> > > > Yes, why not, but the locationmap is not a solution to my problem right
> > > > now, that is how I personally see it. If you can provide an example how
> > > > the lm is solving the fallback mechanism for views without defining all
> > > > the fallbacks in the lm then I will be more then happy to use it.
> > >
> > > Do you meand "the user defining all the fallbacks"? in the sense of
> > > Forrest defining some locations and the user (optionally) defining some.
> > > If so I address this above, otherwise I don't understand your point,
> > > please expand.
> >
> > Here's what I think I understand of the problem. His fallbacks work
> > like this in order:
> >
> > 1. File-based
> > 2. Directory-based
> > 3. Parent-directory based (recursively)
> > 4. Theme based
> > 5. Application Default
> >
>
> Yes, that is right. I will add a doctype specific fallback as well the
> next days which I am right now developing.
>
> > Ok, maybe not exactly, but it gives the general idea. Anyway,
> > locationmaps can solve all of those except, I think, #3. We have no
> > ability to do a "..\" up the directory tree until we find it. We can't
> > dissect the "matcher" result enough to do it either if that makes any
> > sense. I think either way we're probably going to need some java code
> > to do this stuff.
>
> exactly!!! Thanks for writing this down so spot on, Tim. :)
>
> > One might argue that it should be a new selector I
> > suppose -- in which case, I'd say that it should only handle the
> > generic directory traversing part and not forrest-specific defaults.
> > In other words, implement the recursive directory traversal with a new
> > selector and use the built-in capability of the lm to do the rest --
> > that'd give us a more generic directory traversing selector.
>
> Agreed (partly). ;-) The design of the action is quite generic already
> and could be reused in any cocoon based app that needs fallbacks, anyway
> the combination like you suggest seems to be very nice.
>
> Can a selector in the lm provide a map? Can I use:
> <traversal>
> <location src="{calculatedValue}"/>
> </traversal>
>
> If the <traversal> selector returns null then the child will be ignored,
> otherwise it will use the {calculatedValue} that have been placed in the
> returning map of the selector. Is that possible?
I missed this reply. If I understand the question, the answer is kind
of. All null-returning locations would be ignored except the last one
which would, not surprisingly, actually return null, meaning your
example above would also return null. If this is done in the context
of a parent selector, then maybe it would get ignored -- I'd have to
check.
I'll admit that I didn't fully cook the [new traversal selector] idea
in my head before my fingers started typing it;) I think this one
deserves more study and should be filed as a JIRA issue.
--tim
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/
whiteboard/plugins/org.apache.forrest.plugin.inte
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-08-24 at 09:54 -0400, Tim Williams wrote:
...
> > >>If I understand you the functionality is the same, and appears to be
> > >>more flexible in the locationmap (although I'm in a noisy net cafe and
> > >>cannot concentrate fully). Can we stick to just one solution?
> > >
> > >
> > > Yes, why not, but the locationmap is not a solution to my problem right
> > > now, that is how I personally see it. If you can provide an example how
> > > the lm is solving the fallback mechanism for views without defining all
> > > the fallbacks in the lm then I will be more then happy to use it.
> >
> > Do you meand "the user defining all the fallbacks"? in the sense of
> > Forrest defining some locations and the user (optionally) defining some.
> > If so I address this above, otherwise I don't understand your point,
> > please expand.
>
> Here's what I think I understand of the problem. His fallbacks work
> like this in order:
>
> 1. File-based
> 2. Directory-based
> 3. Parent-directory based (recursively)
> 4. Theme based
> 5. Application Default
>
Yes, that is right. I will add a doctype specific fallback as well the
next days which I am right now developing.
> Ok, maybe not exactly, but it gives the general idea. Anyway,
> locationmaps can solve all of those except, I think, #3. We have no
> ability to do a "..\" up the directory tree until we find it. We can't
> dissect the "matcher" result enough to do it either if that makes any
> sense. I think either way we're probably going to need some java code
> to do this stuff.
exactly!!! Thanks for writing this down so spot on, Tim. :)
> One might argue that it should be a new selector I
> suppose -- in which case, I'd say that it should only handle the
> generic directory traversing part and not forrest-specific defaults.
> In other words, implement the recursive directory traversal with a new
> selector and use the built-in capability of the lm to do the rest --
> that'd give us a more generic directory traversing selector.
Agreed (partly). ;-) The design of the action is quite generic already
and could be reused in any cocoon based app that needs fallbacks, anyway
the combination like you suggest seems to be very nice.
Can a selector in the lm provide a map? Can I use:
<traversal>
<location src="{calculatedValue}"/>
</traversal>
If the <traversal> selector returns null then the child will be ignored,
otherwise it will use the {calculatedValue} that have been placed in the
returning map of the selector. Is that possible?
TIA.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
--------------------------------------------------------------
Thorsten Scherler
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401 - in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.inte
Posted by Tim Williams <tw...@apache.org>.
On 8/24/05, Ross Gardler <rg...@apache.org> wrote:
> Thorsten Scherler wrote:
> > On Mon, 2005-08-22 at 18:13 +0100, Ross Gardler wrote:
> >
> >>Thorsten Scherler wrote:
> >>
> >>>On Fri, 2005-08-19 at 09:52 +0100, Ross Gardler wrote:
> >>>
> >>>
> >>>>thorsten@apache.org wrote:
> >>>>
> >>>>
> >>>>>Author: thorsten
> >>>>>Date: Thu Aug 18 17:44:00 2005
> >>>>>New Revision: 233401
> >>>>>
> >>>>
> >>>>...
> >>>>
> >>>>
> >>>>
> >>>>>Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/java/org/apache/forrest/plugin/internal/view/acting/FallbackResolverAction.java
> >>>>
> >>>>Does this fallback resolver work with the locationmap?
> >>>>
> >>>
> >>>
> >>>What do you mean?
> >>
> >>Can I use, for example {lm:{1}} as a URI.
> >>
> >>
> >>>>What does this do that the locationmap does not do?
> >>>>
> >>>
> >>>
> >>>It computes a dynamic path for fallback file.
> >>
> >>...
> >>
> >>
> >>>The locationmap needs to be defined and edited. All fallbacks that you
> >>>want to use, you have to define before, not very suitable for a high
> >>>dynamic environment like views.
> >>
> >>Well something must be telling the fallback where to look. If you change
> >>the defaults that file must be edited too. So there is no difference here.
> >>
> >
> >
> > I do not see how the locationmap can help me with that and I see one big
> > differents:
> > <match pattern="rewriteDemo/**">
> > <select>
> > <location src="http://www.burrokeet.org/{1}.fv" />
> > <!--How can you have dir fallbacks without defining the dir structure
> > here?-->
> > <location src="http://www.burrokeet.org/{dir}{1}.fv" />
> > <location src="http://www.burrokeet.org/default.fv" />
> > </select>
> > </match>
> >
> > Due to the fact that it is a "simple" matcher/select/location mechanism
> > I cannot compute something like the fallback dir view like the action is
> > doing. If I can then please show me an example. Like I see it I need to
> > define all possible locations in a lm.
>
> I think Tims response provides an example, I'm replying in that part of
> the thread.
Not exactly, there's one key difference as I understand it. See below...
> > That is not suitable for views because an user cannot define *all*
> > possible locations. That would mean (s)he has to define all
> > subdirectories of h(er)is site and their fallback in the lm. ...or do I
> > miss something about the locationmap?
>
> There is now the potential for a default forrest locatonmap which will
> import the user locationmap. Therefore Forrest defines the defaults and
> the user can define any extra. In other words it is the same as in your
> fallback resolver in which the defaults are defined in the resolver itself.
Actually, while there is the ability to "mount" a locationmap, I'm
having difficulties with the forrest-mounts-project-locationmap thing
at the moment. When the project-level one doesn't exist, there are
problems. "Assuming" the project-level locationmap exists would break
backwards compatibility. Anyway, I'm having issues with it at the
moment.. I could send a separate description of that and don't want to
put this thread on a tangent.
> >>See http://issues.apache.org/jira/browse/FOR-576 and notice it is Tim
> >>who got this to work so it may be better to have is opinion.
> >>
> >
> >
> > see above, you end up defining all fallbacks there.
> >
> >
> >>If I understand you the functionality is the same, and appears to be
> >>more flexible in the locationmap (although I'm in a noisy net cafe and
> >>cannot concentrate fully). Can we stick to just one solution?
> >
> >
> > Yes, why not, but the locationmap is not a solution to my problem right
> > now, that is how I personally see it. If you can provide an example how
> > the lm is solving the fallback mechanism for views without defining all
> > the fallbacks in the lm then I will be more then happy to use it.
>
> Do you meand "the user defining all the fallbacks"? in the sense of
> Forrest defining some locations and the user (optionally) defining some.
> If so I address this above, otherwise I don't understand your point,
> please expand.
Here's what I think I understand of the problem. His fallbacks work
like this in order:
1. File-based
2. Directory-based
3. Parent-directory based (recursively)
4. Theme based
5. Application Default
Ok, maybe not exactly, but it gives the general idea. Anyway,
locationmaps can solve all of those except, I think, #3. We have no
ability to do a "..\" up the directory tree until we find it. We can't
dissect the "matcher" result enough to do it either if that makes any
sense. I think either way we're probably going to need some java code
to do this stuff. One might argue that it should be a new selector I
suppose -- in which case, I'd say that it should only handle the
generic directory traversing part and not forrest-specific defaults.
In other words, implement the recursive directory traversal with a new
selector and use the built-in capability of the lm to do the rest --
that'd give us a more generic directory traversing selector.
--tim
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/stylesheets/
whiteboard/plugi...)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Mon, 2005-08-22 at 18:13 +0100, Ross Gardler wrote:
>
>>Thorsten Scherler wrote:
>>
>>>On Fri, 2005-08-19 at 09:52 +0100, Ross Gardler wrote:
>>>
>>>
>>>>thorsten@apache.org wrote:
>>>>
>>>>
>>>>>Author: thorsten
>>>>>Date: Thu Aug 18 17:44:00 2005
>>>>>New Revision: 233401
>>>>>
>>>>
>>>>...
>>>>
>>>>
>>>>
>>>>>Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/java/org/apache/forrest/plugin/internal/view/acting/FallbackResolverAction.java
>>>>
>>>>Does this fallback resolver work with the locationmap?
>>>>
>>>
>>>
>>>What do you mean?
>>
>>Can I use, for example {lm:{1}} as a URI.
>>
>>
>>>>What does this do that the locationmap does not do?
>>>>
>>>
>>>
>>>It computes a dynamic path for fallback file.
>>
>>...
>>
>>
>>>The locationmap needs to be defined and edited. All fallbacks that you
>>>want to use, you have to define before, not very suitable for a high
>>>dynamic environment like views.
>>
>>Well something must be telling the fallback where to look. If you change
>>the defaults that file must be edited too. So there is no difference here.
>>
>
>
> I do not see how the locationmap can help me with that and I see one big
> differents:
> <match pattern="rewriteDemo/**">
> <select>
> <location src="http://www.burrokeet.org/{1}.fv" />
> <!--How can you have dir fallbacks without defining the dir structure
> here?-->
> <location src="http://www.burrokeet.org/{dir}{1}.fv" />
> <location src="http://www.burrokeet.org/default.fv" />
> </select>
> </match>
>
> Due to the fact that it is a "simple" matcher/select/location mechanism
> I cannot compute something like the fallback dir view like the action is
> doing. If I can then please show me an example. Like I see it I need to
> define all possible locations in a lm.
I think Tims response provides an example, I'm replying in that part of
the thread.
> That is not suitable for views because an user cannot define *all*
> possible locations. That would mean (s)he has to define all
> subdirectories of h(er)is site and their fallback in the lm. ...or do I
> miss something about the locationmap?
There is now the potential for a default forrest locatonmap which will
import the user locationmap. Therefore Forrest defines the defaults and
the user can define any extra. In other words it is the same as in your
fallback resolver in which the defaults are defined in the resolver itself.
>>See http://issues.apache.org/jira/browse/FOR-576 and notice it is Tim
>>who got this to work so it may be better to have is opinion.
>>
>
>
> see above, you end up defining all fallbacks there.
>
>
>>If I understand you the functionality is the same, and appears to be
>>more flexible in the locationmap (although I'm in a noisy net cafe and
>>cannot concentrate fully). Can we stick to just one solution?
>
>
> Yes, why not, but the locationmap is not a solution to my problem right
> now, that is how I personally see it. If you can provide an example how
> the lm is solving the fallback mechanism for views without defining all
> the fallbacks in the lm then I will be more then happy to use it.
Do you meand "the user defining all the fallbacks"? in the sense of
Forrest defining some locations and the user (optionally) defining some.
If so I address this above, otherwise I don't understand your point,
please expand.
Ross
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/stylesheets/
whiteboard/plugi...)
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-08-22 at 18:13 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Fri, 2005-08-19 at 09:52 +0100, Ross Gardler wrote:
> >
> >>thorsten@apache.org wrote:
> >>
> >>>Author: thorsten
> >>>Date: Thu Aug 18 17:44:00 2005
> >>>New Revision: 233401
> >>>
> >>
> >>...
> >>
> >>
> >>>Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/java/org/apache/forrest/plugin/internal/view/acting/FallbackResolverAction.java
> >>
> >>Does this fallback resolver work with the locationmap?
> >>
> >
> >
> > What do you mean?
>
> Can I use, for example {lm:{1}} as a URI.
>
> >>What does this do that the locationmap does not do?
> >>
> >
> >
> > It computes a dynamic path for fallback file.
>
> ...
>
> > The locationmap needs to be defined and edited. All fallbacks that you
> > want to use, you have to define before, not very suitable for a high
> > dynamic environment like views.
>
> Well something must be telling the fallback where to look. If you change
> the defaults that file must be edited too. So there is no difference here.
>
I do not see how the locationmap can help me with that and I see one big
differents:
<match pattern="rewriteDemo/**">
<select>
<location src="http://www.burrokeet.org/{1}.fv" />
<!--How can you have dir fallbacks without defining the dir structure
here?-->
<location src="http://www.burrokeet.org/{dir}{1}.fv" />
<location src="http://www.burrokeet.org/default.fv" />
</select>
</match>
Due to the fact that it is a "simple" matcher/select/location mechanism
I cannot compute something like the fallback dir view like the action is
doing. If I can then please show me an example. Like I see it I need to
define all possible locations in a lm.
That is not suitable for views because an user cannot define *all*
possible locations. That would mean (s)he has to define all
subdirectories of h(er)is site and their fallback in the lm. ...or do I
miss something about the locationmap?
> > The action reads a location (uri) and scans it whether a file exist. If
> > not it will scan for any project specific fallbacks that may exist (see
> > above). After this it scans further for default fallbacks (see
> > FallbackResolverAction.java). Actually in above code we now can easily
> > instance the SourceTypeAction [1] and implement "content aware
> > views" (FOR-621).
> >
> > Can the loactionmap help me with all that?
>
> Yes, at least to the first part, the second part needs work, as with the
> fallback resolver.
>
No, the first cannot be solved with the lm. *ONLY* if you define the
whole fallback list (like stated above).
> See http://issues.apache.org/jira/browse/FOR-576 and notice it is Tim
> who got this to work so it may be better to have is opinion.
>
see above, you end up defining all fallbacks there.
> If I understand you the functionality is the same, and appears to be
> more flexible in the locationmap (although I'm in a noisy net cafe and
> cannot concentrate fully). Can we stick to just one solution?
Yes, why not, but the locationmap is not a solution to my problem right
now, that is how I personally see it. If you can provide an example how
the lm is solving the fallback mechanism for views without defining all
the fallbacks in the lm then I will be more then happy to use it.
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.inte
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Mon, 2005-08-22 at 16:29 -0400, Tim Williams wrote:
>
>
>>Assuming I understand what this is doing, I don't immediately see why
>>this couldn't be done with either the locationmap or a
>>ResourceExistsSelector in the sitemap itself.
>
>
> We had the ResourceExistsSelector in the views sitemaps (and some parts
> are still using this selector). The FallbackResolverAction is an attempt
> to have a cleaner sitemap.
Yes, same goal of the selector in the Locationmap.
>> Below is a very rough
>>idea of what the locationmap version of this would be I think. Maybe
>>there's something that the FallbackResolver is doing that I'm just not
>>"seeing" though?
>>
>
>
> Requesting
> http://localhost:8888/samples/sample.html
>
> The FallbackResolverAction.java will try:
> 1) xdocs/samples/sample.{project:theme-ext}
> 2) xdocs/samples/{project:theme}.{project:theme-ext}
> 3) xdocs/{project:theme}.{project:theme-ext}
> 4) {defaults:view-themes}/{project:theme}.{project:theme-ext}
> 5) {defaults:view-themes}/{project:theme}.{defaults:theme-ext}
>
> The FallbackResolver is "looping" through the directories downwards till
> the last project specific fallback is reached.
> How can I implement this recursive looping behavior (1,2) in the lm? The
> important part is that the incoming request would be "samples/sample"
> for {1}.
What do you mean recursive "looping"? I don't see a loop above. I see 5
alternative locations, each of which will be tested for the location of
the file, if it exists it will be loaded, if not the next will be tried.
What part of this is a recursive loop and why?
Lets find a way of getting the required functionlaity into the
locationmap, but first we need to understand why this is not currently
possible.
When I get back home (end of this week). I'll spend some time digesting
your fallback resolver and its use.
Ross
Ross
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/
whiteboard/plugins/org.apache.forrest.plugin.inte
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-08-22 at 16:29 -0400, Tim Williams wrote:
> Assuming I understand what this is doing, I don't immediately see why
> this couldn't be done with either the locationmap or a
> ResourceExistsSelector in the sitemap itself.
We had the ResourceExistsSelector in the views sitemaps (and some parts
are still using this selector). The FallbackResolverAction is an attempt
to have a cleaner sitemap.
> Below is a very rough
> idea of what the locationmap version of this would be I think. Maybe
> there's something that the FallbackResolver is doing that I'm just not
> "seeing" though?
>
Requesting
http://localhost:8888/samples/sample.html
The FallbackResolverAction.java will try:
1) xdocs/samples/sample.{project:theme-ext}
2) xdocs/samples/{project:theme}.{project:theme-ext}
3) xdocs/{project:theme}.{project:theme-ext}
4) {defaults:view-themes}/{project:theme}.{project:theme-ext}
5) {defaults:view-themes}/{project:theme}.{defaults:theme-ext}
The FallbackResolver is "looping" through the directories downwards till
the last project specific fallback is reached.
How can I implement this recursive looping behavior (1,2) in the lm? The
important part is that the incoming request would be "samples/sample"
for {1}.
> <map:match pattern="prepare.view.**">
> <map:generate src="{lm:prepare.view.{1}}"/>
> <map:transform src="resources/stylesheets/prepare.include.templates.xsl"/>
> <map:transform type="xinclude"/>
> <map:serialize type="xml"/>
> </map:match>
>
> <locator>
> <match pattern="prepare.view.**.*">
> <select>
> <location src="{1}.{2}"/>
> <location src="{project:theme}{1}.{project:theme-ext}"/>
> <location src="{project:content.xdocs}{1}.{project:theme-ext}"/>
> <location src="{defaults:view-themes}...
> <location src="{defaults:theme}...
> </select>
> </match>
> </locator>
This example is missing the looping. Anyway, thanks for giving it. :)
> --tim
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401 - in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.inte
Posted by Tim Williams <wi...@gmail.com>.
On 8/22/05, Ross Gardler <rg...@apache.org> wrote:
> Thorsten Scherler wrote:
> > On Fri, 2005-08-19 at 09:52 +0100, Ross Gardler wrote:
> >
> >>thorsten@apache.org wrote:
> >>
> >>>Author: thorsten
> >>>Date: Thu Aug 18 17:44:00 2005
> >>>New Revision: 233401
> >>>
> >>
> >>...
> >>
> >>
> >>>Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/java/org/apache/forrest/plugin/internal/view/acting/FallbackResolverAction.java
> >>
> >>Does this fallback resolver work with the locationmap?
> >>
> >
> >
> > What do you mean?
>
> Can I use, for example {lm:{1}} as a URI.
>
> >>What does this do that the locationmap does not do?
> >>
> >
> >
> > It computes a dynamic path for fallback file.
>
> ...
>
> > The locationmap needs to be defined and edited. All fallbacks that you
> > want to use, you have to define before, not very suitable for a high
> > dynamic environment like views.
>
> Well something must be telling the fallback where to look. If you change
> the defaults that file must be edited too. So there is no difference here.
>
> > The action reads a location (uri) and scans it whether a file exist. If
> > not it will scan for any project specific fallbacks that may exist (see
> > above). After this it scans further for default fallbacks (see
> > FallbackResolverAction.java). Actually in above code we now can easily
> > instance the SourceTypeAction [1] and implement "content aware
> > views" (FOR-621).
> >
> > Can the loactionmap help me with all that?
>
> Yes, at least to the first part, the second part needs work, as with the
> fallback resolver.
>
> See http://issues.apache.org/jira/browse/FOR-576 and notice it is Tim
> who got this to work so it may be better to have is opinion.
>
> If I understand you the functionality is the same, and appears to be
> more flexible in the locationmap (although I'm in a noisy net cafe and
> cannot concentrate fully). Can we stick to just one solution?
>
> Ross
Assuming I understand what this is doing, I don't immediately see why
this couldn't be done with either the locationmap or a
ResourceExistsSelector in the sitemap itself. Below is a very rough
idea of what the locationmap version of this would be I think. Maybe
there's something that the FallbackResolver is doing that I'm just not
"seeing" though?
<map:match pattern="prepare.view.**">
<map:generate src="{lm:prepare.view.{1}}"/>
<map:transform src="resources/stylesheets/prepare.include.templates.xsl"/>
<map:transform type="xinclude"/>
<map:serialize type="xml"/>
</map:match>
<locator>
<match pattern="prepare.view.**.*">
<select>
<location src="{1}.{2}"/>
<location src="{project:theme}{1}.{project:theme-ext}"/>
<location src="{project:content.xdocs}{1}.{project:theme-ext}"/>
<location src="{defaults:view-themes}...
<location src="{defaults:theme}...
</select>
</match>
</locator>
--tim
Re: Fallback resolver Vs. Locationmap (was Re: svn commit: r233401
- in /forrest/trunk: main/webapp/ main/webapp/WEB-INF/xconf/ site-author/
whiteboard/plugins/org.apache.forrest.plugin.internal.view/ whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/stylesheets/
whiteboard/plugi...)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2005-08-19 at 09:52 +0100, Ross Gardler wrote:
>
>>thorsten@apache.org wrote:
>>
>>>Author: thorsten
>>>Date: Thu Aug 18 17:44:00 2005
>>>New Revision: 233401
>>>
>>
>>...
>>
>>
>>>Added: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/java/org/apache/forrest/plugin/internal/view/acting/FallbackResolverAction.java
>>
>>Does this fallback resolver work with the locationmap?
>>
>
>
> What do you mean?
Can I use, for example {lm:{1}} as a URI.
>>What does this do that the locationmap does not do?
>>
>
>
> It computes a dynamic path for fallback file.
...
> The locationmap needs to be defined and edited. All fallbacks that you
> want to use, you have to define before, not very suitable for a high
> dynamic environment like views.
Well something must be telling the fallback where to look. If you change
the defaults that file must be edited too. So there is no difference here.
> The action reads a location (uri) and scans it whether a file exist. If
> not it will scan for any project specific fallbacks that may exist (see
> above). After this it scans further for default fallbacks (see
> FallbackResolverAction.java). Actually in above code we now can easily
> instance the SourceTypeAction [1] and implement "content aware
> views" (FOR-621).
>
> Can the loactionmap help me with all that?
Yes, at least to the first part, the second part needs work, as with the
fallback resolver.
See http://issues.apache.org/jira/browse/FOR-576 and notice it is Tim
who got this to work so it may be better to have is opinion.
If I understand you the functionality is the same, and appears to be
more flexible in the locationmap (although I'm in a noisy net cafe and
cannot concentrate fully). Can we stick to just one solution?
Ross