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: > >> > >>http://domain.com/resume/complete_view/blogs.html > >>http://domain.com/resume/summary_view/blogs.html > >> > >>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: http://forRoss.com/lenya/test.html http://forRoss.com/lenya/testAnother.html You define <map:match pattern="lenya/**.xml"> <map:generate src="{lm:{1}.xml}"/> <map:serialize type="xml"/> </map:match> 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 resolver. 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 having > +-- 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: requesting: http://forRoss.com/resume/test.summary.html http://forRoss.com/resume/test.complete.html or simpler: test.summary.html test.complete.html Now we would have e.g. an action that strips the part after the extension and before the file name. Leads us to summary complete This action would put the striped part in the request as parameter. setParameter("multipleView","summary"); Then the normal processing takes place and it goes into the jx based view template. Here it will get picked up. <jx:choose> <jx:when test="${cocoon.request.multipleView.equal("summary")}"> SUMMARY VIEW </jx:when> <jx:when test="${cocoon.request.multipleView.equal("complete")}"> COMPLETE VIEW </jx:when> <jx:otherwise> FALLBACK VIEW </jx:otherwise> </jx:choose> 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 shoot. Anyway, wdyt? salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
