Tim Williams wrote:
On 8/31/05, Ross Gardler <[EMAIL PROTECTED]> wrote:


...

I have a number of resumes, one for each member of staff. The staff love
the fact that they can each have a unique layout for their CV, whilst
still keeping the company branding on their pages - very impressive and
certainly an excellent use case for views

...

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?

Ross


It sounds like Cocoon's "Views" would be more appropriate, allowing
you to do something like this:
http://domain.com/resume/blogs.html?view=complete
http://domain.com/resume/blogs.html?view=summary

Your use-case sounds a lot like the description of cocoon views. Maybe you're not going that route for a reason though?

Using a parameter in the URL is not an option since these do not make for valid filenames and therefore it is impossible to generate a static site (a requirement in this use case).

Furthermore, if I understand Cocoon views correctly, they allow me to stop processing at a certain point in the pipeline in order to get a different view. This is not what I want to do, I am changing what is displayed not how it is processed.

(your response gives another strong indicator that the name "view" is incorrect, we really need to resolve this naming issue)

Of course I can do it with the sitemap, filtering out the parts that I don't want at the point of generating the XDoc.

I'm just exploring to see what the limitations of forrest:views are and if it makes sense to do this kind of work there rather than in the sitemap.

You see, ultimately, I would like to be able to provide a parameterised template that would allow *users* to specifiy what is in their view by editing a config file. I'm just working out where the best palce to do this is. Prior to forrest:views I would, without hesitation, have done it in the sitemap. Now I can see that it may be possible in forrest:views (I'm not saying this is the right thing to do though).

Ross

Reply via email to