You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/08/31 13:20:50 UTC
Different views for the same source file
Here's a tough one. I'm not sure how best to solve it since 'm still
digging around in the sitemaps for views (I think I'm starting to
understand the implementation as well as the theory now ;-)
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
[OT] This plugin will make a great place to show the power of views.
Unfortunately, none of my work is documented in the plugin yet,
hopefully I'll find the time, but not until I finish this project.
Anyway, to the problem.
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
Re: Different views for the same source file
Posted by Thorsten Scherler <th...@apache.org>.
I have to think about this. ;-)
Will write you after work.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Different views for the same source file
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> ...
> > I don't have the time to find that discussion right now. Anyone have a
> > clearer recollection to be able to search for it quickly (my first few
> > attempts failed so it's back to the deadline beating)...
>
> Ok, found it... how stupid of me, I had written it down in
>
> forrest/site-author/content/xdocs/TR/2004/WD-forrest10.html
>
> "
> In the second step, Forrest transforms the main source to the
> intermediate format, which is XHTML2 (also automatic transforms from
> XHTML1 and HTML will be supported). Transformations from HTML and XHTML
> will be done in the core, while all others will be done by plugins
> (input plugins).
>
> Multiple formats can be asked for the same source: the filename asked
> will be in the following manner.
>
> name.type.format
>
> Example:
>
> myfile.content.html
> myfile.javadocs.html
> myfile.html
> "
I also remember that Marc Portier was involved in a big
discussion about that. Google helped me to find this:
http://marc.theaimsgroup.com/?t=103081675500002
[VOTE] Usage of file.hint.ext convention
but i am sure that there was also another proposal from him
which i cannot find.
-David
Re: Different views for the same source file
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> ...
>
>>I don't have the time to find that discussion right now. Anyone have a
>>clearer recollection to be able to search for it quickly (my first few
>>attempts failed so it's back to the deadline beating)...
>
>
> Ok, found it... how stupid of me, I had written it down in
>
> forrest/site-author/content/xdocs/TR/2004/WD-forrest10.html
>
> "
> In the second step, Forrest transforms the main source to the
> intermediate format, which is XHTML2 (also automatic transforms from
> XHTML1 and HTML will be supported). Transformations from HTML and XHTML
> will be done in the core, while all others will be done by plugins
> (input plugins).
>
> Multiple formats can be asked for the same source: the filename asked
> will be in the following manner.
>
> name.type.format
>
> Example:
>
> myfile.content.html
> myfile.javadocs.html
> myfile.html
> "
>
Thanks, no time to go over it now. However, it looks like the meme had
been firmly planted. That is the format I have been using in the Daisy
plugin and the new *.source.xml ability in input plugins.
It is also the format Thorsten suggested in his proposal for this thread.
We have better memories than we think ;-)
I'll re-read the relevant docs soon (and the Marc Portier one David
links to).
Thanks folks,
Ross
Re: Different views for the same source file
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
...
> I don't have the time to find that discussion right now. Anyone have a
> clearer recollection to be able to search for it quickly (my first few
> attempts failed so it's back to the deadline beating)...
Ok, found it... how stupid of me, I had written it down in
forrest/site-author/content/xdocs/TR/2004/WD-forrest10.html
"
In the second step, Forrest transforms the main source to the
intermediate format, which is XHTML2 (also automatic transforms from
XHTML1 and HTML will be supported). Transformations from HTML and XHTML
will be done in the core, while all others will be done by plugins
(input plugins).
Multiple formats can be asked for the same source: the filename asked
will be in the following manner.
name.type.format
Example:
myfile.content.html
myfile.javadocs.html
myfile.html
"
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Different views for the same source file
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
>
>>Tim Williams wrote:
>
> ...
>
>>>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).
>
> ...
>
>>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).
>
>
> We already had this discussion (without the views implication part).
>
> In practice, pdf output, text output, html output, etc are different
> "views" already, and they differentiate only for the extension.
>
> This can and should be generalized, also because in an ideal web, there
> would be no extension, just a request that is given the best content
> given the client capabilities.
>
> The result was that to specify manually the output type, the name of the
> file would have to change, in a way similar to what is used by Apache
> HTTPD for multilingual sites.
>
> Damn, I don't remember the thread, but we had come up with a decision on
> how to define the filename. Rats.
I recall the discussion. You are right what I am proposing here could
also be applied to that problem, although the use case here is different
since it is the content not the output format that changes.
In another mail Thorsten suggested a hack for this that will work with
no code modification. It's worth considering this hack as a solution to
the "extension" problem described in the discussion in our archives.
I don't have the time to find that discussion right now. Anyone have a
clearer recollection to be able to search for it quickly (my first few
attempts failed so it's back to the deadline beating)...
Ross
Re: Different views for the same source file
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> Tim Williams wrote:
...
>> 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).
...
> 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).
We already had this discussion (without the views implication part).
In practice, pdf output, text output, html output, etc are different
"views" already, and they differentiate only for the extension.
This can and should be generalized, also because in an ideal web, there
would be no extension, just a request that is given the best content
given the client capabilities.
The result was that to specify manually the output type, the name of the
file would have to change, in a way similar to what is used by Apache
HTTPD for multilingual sites.
Damn, I don't remember the thread, but we had come up with a decision on
how to define the filename. Rats.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Different views for the same source file
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 8/31/05, Ross Gardler <rg...@apache.org> 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
Re: Different views for the same source file
Posted by Tim Williams <wi...@gmail.com>.
On 8/31/05, Ross Gardler <rg...@apache.org> wrote:
> Here's a tough one. I'm not sure how best to solve it since 'm still
> digging around in the sitemaps for views (I think I'm starting to
> understand the implementation as well as the theory now ;-)
>
> 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
>
> [OT] This plugin will make a great place to show the power of views.
> Unfortunately, none of my work is documented in the plugin yet,
> hopefully I'll find the time, but not until I finish this project.
>
> Anyway, to the problem.
>
> 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?
--tim
Re: Different views for the same source file
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-08-31 at 22:27 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
...
>
> 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.
No, only the ones with multiple views for a single source. The other can
stay like they are.
> But I guess
> jxtempaltes allow me to import external files.
>
Actually, yes and it will give you what you always wanted. Remember your
forrest:import suggestion? ;-)
BTW the suggestion to base views on jx:templates came originally from
Nicola. The nice thing on it: we do not have to implement my former
logic:bla stuff because that comes for free with jx templates (like lots
of other things).
[I hear Gregor clapping in his hands ;-)]
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Different views for the same source file
Posted by Ross Gardler <rg...@apache.org>.
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
Re: Different views for the same source file
Posted by Thorsten Scherler <th...@apache.org>.
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)
Re: Different views for the same source file
Posted by Ross Gardler <rg...@apache.org>.
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
Re: Different views for the same source file
Posted by Thorsten Scherler <th...@apache.org>.
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?
HTH
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)