Conditional application of dispatcher contracts

How can I change the behavior of a dispatcher contract
depending on
the page being requested?

Specifically, how can I make a template be used for a
request of
"projectDetails/foo.html" and
"projectDetails/foo/bar.html", but not
for "projectDetails/index/byCategory.html"?

Note that overriding the theme with
"projectDetails/theme.fv" and
"projectDetails/index/theme.fv" does not work as I
would have
expected, the second theme requested is never used. This
looks like a
cache problem, is it?

Ross

On Tue, 2007-06-12 at 23:00 +0100, Ross Gardler wrote:
> How can I change the behavior of a dispatcher contract
depending on
> the page being requested?
> 
> Specifically, how can I make a template be used for a
request of
> "projectDetails/foo.html" and
"projectDetails/foo/bar.html", but not
> for "projectDetails/index/byCategory.html"?

1) implementing in 
${project.resources-dir}/structurer/url
mkdir -p projectDetails/foo
mkdir -p projectDetails/index
vi projectDetails/foo/${dispatcher.theme}.fv
vi projectDetails/index/${dispatcher.theme}.fv

Important is that the template name is equal to
${dispatcher.theme}!

2) implementing presentation logic in the main
${dispatcher.theme}.fv
like:
<jx:if test="${!
getRequest.contains('projectDetails/index/byCategory')}"
;>
 <forrest:contract name="myContract"/>
</jx:if>

> 
> Note that overriding the theme with
"projectDetails/theme.fv" and
> "projectDetails/index/theme.fv" does not work
as I would have
> expected, the second theme requested is never used. 
> This looks like a
> cache problem, is it?

Hmm, not sure would be new. Should work fine: is the
template name equal
to ${dispatcher.theme}?

salu2
-- 
Thorsten Scherler                                
thorsten.at.apache.org
Open Source Java                      consulting, training
and solutions

On 13/06/07, Thorsten Scherler <thorstenapache.org> wrote:
> On Tue, 2007-06-12 at 23:00 +0100, Ross Gardler wrote:
> > How can I change the behavior of a dispatcher
contract depending on
> > the page being requested?
> >
> > Specifically, how can I make a template be used
for a request of
> > "projectDetails/foo.html" and
"projectDetails/foo/bar.html", but not
> > for
"projectDetails/index/byCategory.html"?
>
> 1) implementing in
> ${project.resources-dir}/structurer/url
> mkdir -p projectDetails/foo
> mkdir -p projectDetails/index
> vi projectDetails/foo/${dispatcher.theme}.fv
> vi projectDetails/index/${dispatcher.theme}.fv
>
> Important is that the template name is equal to
${dispatcher.theme}!

This doesn't work, there must be a bug. I've created a test
case in
the dispatcher docs and will file a bug report in a moment.

> 2) implementing presentation logic in the main
${dispatcher.theme}.fv
> like:
> <jx:if test="${!
>
getRequest.contains('projectDetails/index/byCategory')}"
;>
>  <forrest:contract name="myContract"/>
> </jx:if>

Ahhh - of course. So obvious when it's pointed out.

Thanks,
Ross

On 6/13/07, Thorsten Scherler <thorstenapache.org> wrote:
> On Tue, 2007-06-12 at 23:00 +0100, Ross Gardler wrote:
> > Note that overriding the theme with
"projectDetails/theme.fv" and
> > "projectDetails/index/theme.fv" does not
work as I would have
> > expected, the second theme requested is never
used.
> > This looks like a
> > cache problem, is it?
>
> Hmm, not sure would be new. Should work fine: is the
template name equal
> to ${dispatcher.theme}?

I've also experienced this issue in dynamic mode. In my
case, the
sequence is (from memory): 1) visit page with default
structurer--works fine; 2) visit page with overridden
structurer--works fine; 3) visit page with default
structurer--non-default structurer from step 2 is used. If I
recall,
static mode generation was correct.

Brian

On 13/06/07, Brian M Dube <bdubeapache.org> wrote:
> On 6/13/07, Thorsten Scherler <thorstenapache.org> wrote:
> > On Tue, 2007-06-12 at 23:00 +0100, Ross Gardler
wrote:
> > > Note that overriding the theme with
"projectDetails/theme.fv" and
> > > "projectDetails/index/theme.fv"
does not work as I would have
> > > expected, the second theme requested is never
used.
> > > This looks like a
> > > cache problem, is it?
> >
> > Hmm, not sure would be new. Should work fine: is
the template name equal
> > to ${dispatcher.theme}?
>
> I've also experienced this issue in dynamic mode. In my
case, the
> sequence is (from memory): 1) visit page with default
> structurer--works fine; 2) visit page with overridden
> structurer--works fine; 3) visit page with default
> structurer--non-default structurer from step 2 is used.
If I recall,
> static mode generation was correct.

Did you see Thorstens subsequent mails. Apparently putting
overrides
of the structurer in the content/xdocs directory is
deprecated, and
doesn't work.

However, the *.fv files in
/src/content/resources/structurer/url/foo/bar works.

I put a test case (which forms a kind of documentation) in
the
dispatcher plugin and Thorsten has now fixed it.

Ross

On 6/14/07, Ross Gardler <rgardlerapache.org> wrote:
> On 13/06/07, Brian M Dube <bdubeapache.org> wrote:
> > On 6/13/07, Thorsten Scherler <thorstenapache.org> wrote:
> > > On Tue, 2007-06-12 at 23:00 +0100, Ross
Gardler wrote:
> > > > Note that overriding the theme with
"projectDetails/theme.fv" and
> > > >
"projectDetails/index/theme.fv" does not work as I
would have
> > > > expected, the second theme requested is
never used.
> > > > This looks like a
> > > > cache problem, is it?
> > >
> > > Hmm, not sure would be new. Should work fine:
is the template name equal
> > > to ${dispatcher.theme}?
> >
> > I've also experienced this issue in dynamic mode.
In my case, the
> > sequence is (from memory): 1) visit page with
default
> > structurer--works fine; 2) visit page with
overridden
> > structurer--works fine; 3) visit page with
default
> > structurer--non-default structurer from step 2 is
used. If I recall,
> > static mode generation was correct.
>
> Did you see Thorstens subsequent mails. Apparently
putting overrides
> of the structurer in the content/xdocs directory is
deprecated, and
> doesn't work.
>
> However, the *.fv files in
/src/content/resources/structurer/url/foo/bar works.
>
> I put a test case (which forms a kind of documentation)
in the
> dispatcher plugin and Thorsten has now fixed it.

I've never tried it in content/xdocs. I had this issue in
content/resources/structurer/url. The structurer(s) work
fine. It acts
like an intermittent cache issue.

Brian

On 15/06/07, Brian M Dube <bdubeapache.org> wrote:
> On 6/14/07, Ross Gardler <rgardlerapache.org> wrote:
> > On 13/06/07, Brian M Dube <bdubeapache.org> wrote:
> > > On 6/13/07, Thorsten Scherler
<thorstenapache.org> wrote:
> > > > On Tue, 2007-06-12 at 23:00 +0100, Ross
Gardler wrote:
> > > > > Note that overriding the theme with
"projectDetails/theme.fv" and
> > > > >
"projectDetails/index/theme.fv" does not work as I
would have
> > > > > expected, the second theme
requested is never used.
> > > > > This looks like a
> > > > > cache problem, is it?
> > > >
> > > > Hmm, not sure would be new. Should work
fine: is the template name equal
> > > > to ${dispatcher.theme}?
> > >
> > > I've also experienced this issue in dynamic
mode. In my case, the
> > > sequence is (from memory): 1) visit page with
default
> > > structurer--works fine; 2) visit page with
overridden
> > > structurer--works fine; 3) visit page with
default
> > > structurer--non-default structurer from step
2 is used. If I recall,
> > > static mode generation was correct.
> >
> > Did you see Thorstens subsequent mails. Apparently
putting overrides
> > of the structurer in the content/xdocs directory
is deprecated, and
> > doesn't work.
> >
> > However, the *.fv files in
/src/content/resources/structurer/url/foo/bar works.
> >
> > I put a test case (which forms a kind of
documentation) in the
> > dispatcher plugin and Thorsten has now fixed it.
>
> I've never tried it in content/xdocs. I had this issue
in
> content/resources/structurer/url. The structurer(s)
work fine. It acts
> like an intermittent cache issue.

Well now I have moved to the correct location everything
seems to work
fine for me. That being said, it's not been tested by a
significant
number of people yet.

Ross