forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Different views for the same source file
Date Wed, 31 Aug 2005 21:27:42 GMT
Thorsten Scherler wrote:
> 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...

...

> 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.

Doh! You are right, I had already implemented the very solution you 
describe in a different use case.

> 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"

...

> I will have no time tonight, so I cannot try. I reckon it is worth a
> shoot. 
> 
> Anyway, wdyt?

I think your idea sounds like a sensible one. I'm happy with the hack 
for now. But if you want to try this out I'll be even happier. My only 
concern is that all *.fv files will be in a single file. But I guess 
jxtempaltes allow me to import external files.

Ross

Mime
View raw message