forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Different views for the same source file
Date Wed, 31 Aug 2005 18:40:32 GMT
On Wed, 2005-08-31 at 16:28 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > What I tell you is just a quick thought that I was having while
> > lunch. ;-)
> > 
> > I saw your commits and still have to check your code. Anyway here it
> > goes.
> > 
> > On Wed, 2005-08-31 at 12:20 +0100, Ross Gardler wrote:
> > <snip introduction>
> > 
> >>We need to be able to present different views on each source file. For 
> >>example, the blogs.xml resume needs to be presented with a number of 
> >>different views. Each view will have different content, for example, the 
> >>"complete" view will have all project history with full details of all 
> >>projects no matter how long ago they took place. The "recent" view will 
> >>show the full details of the most recent job and a summary of each of 
> >>the earlier projects.
> >>
> >>I'm not at all sure how to do this. I guess the view name will be 
> >>provided in the URL:
> >>
> >>
> >>
> >>
> >>Any hints on how I then pass that to the view resolver in the 
> >>internal.view plugin?
> > 
> > 
> > Actually I did a similar thing once. What you can do is create the
> > directories resume/complete_view and resume/summary_view in your project
> > and add the views. If you use the default.fv (or the name you have
> > choosen) in this directories then all the pages will use this view.
> > 
> > What happens here is that the plugin will deliver the main content when
> > requesting above links (not the project file system) and the view
> > resolver will match the views in the directory structure.
> > 
> > Actually this approach only works if the content is coming from a plugin
> > and you have a project. Not 100% true because the is a way to implement
> > it against a file structure, but that is not what you requested, or?
> > 
> > Does that makes sense to you?
> I think I understand, is this what you mean...
> <map:match pattern="resume/*/**.xml">
>    <map:generate src="cocoon://resume/{2}.xml"/>
>    <map:serialize type="xml"/>
> </map:match>
> Thus we strip the theme from the URL, but it is still present when the 
> view does its stuff. Then we can have:
> --+ resume
>       |
>       +-- blogs.xml
>       +-- doh.xml
>       +-- default.fv
>       +-- complete
>       |     |
>       |     +-- default.fv
>       +-- summary
>             |
>             +-- default.fv
> I'm pretty sure this will work, but I have to admit it feels like a hack 
> since I'm touching the project sitemap *and* the directory structure.
> Of course, a hack is a quick solution, if we find this truly useful then 
> we can find a way of getting this into the view-resolver so the 
> directory structure will be:
> --+ resume
>       |
>       +-- blogs.xml
>       +-- doh.xml
>       +-- default.fv
>       +-- complete.fv
>       +-- summary.fv
> and there will be no need to touch the project sitemap (the match will 
> be in the plugin sitemap).
> Thanks for the pointer.
> Ross

Actually my idea was based on the lm but it was working like you
describe (and it was working for me back then). I tried once with the
lenya lm match we had in the lm branch.

The idea (back then) was that your request is:

You define
<map:match pattern="lenya/**.xml">
   <map:generate src="{lm:{1}.xml}"/>
   <map:serialize type="xml"/>

With help of the dir structure, that have been empty, because you could
not have a lenya dir in your xdocs that where actually serving content
(that came from the lenya server), you could use the normal view

Your point that this seems like a hack because we touching two things is
valid. You wrote:
"Of course, a hack is a quick solution, if we find this truly useful
then we can find a way of getting this into the view-resolver"

Actually the problem is to parsing it to the view resolver. You answered
Tim that parameter are not an option. Nicola just refreshed my memories
with the traversable source (it is that, or not?).

One option to get a away from this hack (which is actually quite
accurate for some usecases ;-)) is to use e.g. session objects and
basing the fv on jxtemplates. 

That allows to check conditions and deliver the right view. Instead of
>       +-- complete.fv
>       +-- summary.fv

You would have blog.fv which will contain both views. Depending which is
requested it get delivered. That as well brings us more to were we once
started talking about user-specific views. 

Let me draw a picture:
or simpler:

Now we would have e.g. an action that strips the part after the
extension and before the file name. Leads us to 

This action would put the striped part in the request as parameter.
Then the normal processing takes place and it goes into the jx based
view template. Here it will get picked up.
  <jx:when test="${cocoon.request.multipleView.equal("summary")}">
  <jx:when test="${cocoon.request.multipleView.equal("complete")}">

I am pretty sure that it will work this way and to base view on jx is
just a change of the generator type.

I will have no time tonight, so I cannot try. I reckon it is worth a

Anyway, wdyt?


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message