You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2005/07/05 02:45:54 UTC
[views] Dir specific view
Hello devs,
I added the dir specific view matcher to the location map. Will try to
merge tomorrow the view specific stuff back to trunk.
<!--
*viewSelector*
will return which view is responsible for the requested path.
If no view (choice|fallback) could be found the template will return the viewFallback
(plugin specific default.fv).
ex.:
1.request: index
First choice: index.fv
First/last fallback: default.fv
2.request: sample/index
First choice: sample/index.fv
First fallback: sample/default.fv
Last fallback: default.fv
3.request: sample/subdir/index
First choice: sample/subdir/index.fv
First fallback: sample/subdir/default.fv
Second fallback: sample/default.fv
Last fallback: default.fv
...
des.:
The parent view (root-view) inherits to its children until
a child is overriding this view. This override can be used for
directories (default.fv) and/or files (*.fv).
That means that the root view is the default view as long no other
view can be found in the requested child.
-->
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [views] Dir specific view
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2005-07-05 at 09:03 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > I added the dir specific view matcher to the location map. Will try to
> > merge tomorrow the view specific stuff back to trunk.
>
> Awesome!!!
>
> Ross
:)
just for you ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [views] Dir specific view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> I added the dir specific view matcher to the location map. Will try to
> merge tomorrow the view specific stuff back to trunk.
Awesome!!!
Ross
Re: [views] Dir specific view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
>>Question 1:
>>
>>Do you see a problem with having the same fallback mechanism that you
>>have created for the *.ft files?
>>
>
>
> Actually that is possible.
>
> ...but you mean *.fv (forrest:views), or?
>
> ...or better ask you mean the mechanism I implemented with the
> viewLocationmap.xml? In this case it would be viewTemplatesmap, or?
I have no idea what you mean by "viewLocationmap.xml". I'll come back to
you when I have had chance to understand this work.
I *think* we are talking about the same thing, but I can't comment on
your solution because I'm not fully up to speed with views yet. Since
ApacheCon is now only a week away I will spend some time this week
really understanding your code. Then we can attack these issues
face-to-face.
>>Question 2:
>>
>>Should we merge all this stuff together into a single document so the
>>templates are defined in the *.fv file? We can then add a
>><forrest:import src="default.fv"> and override elements within that (as
>>we do in XSL). This would reduce the number of files quite considerably
>>and make editing by hand much easier (at least I believe so)
>>
>
>
> Hmm, what do you mean? I am unsure whether I understood you right. Right
> now we splitting things apart for easy maintainment but on the other
> hand you want to merge them again?
The separation we wanted was to get meta-data and view-config separate.
However, we now seem to be going to the opposite extreme of a single
file for everything, we now have one file for each tiny peice of
functionality. This would be fine if we had a GUI doing all our editing,
but doing it by hand is a pain. That is, the separation is no longer
along the lines of meta-data and view data (which you have achieved
nively with contracts and views), things have gone a step further, to
separating the meta data for each individual template.
I'm wondering if we should take a leaf out of XSLs book where we have:
<xsl:template name="aTemplate">
...
</xsl:template>
<xsl:template name="anotherTemplate">
...
</xsl:template>
<xsl:template name="yetAnotherTemplate">
...
</xsl:template>
(this is the equivalent of view contracts)
These are then used as:
<xsl:call-template name="aTemplate"/>
etc.
Using the <xsl:import...> element we can group contracts together for
easy management.
Ross
Re: [views] Dir specific view
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-07-08 at 08:30 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2005-07-07 at 22:32 +0200, Thorsten Scherler wrote:
> >
> >>On Thu, 2005-07-07 at 16:48 +0100, Ross Gardler wrote:
> >>
> >>>Thorsten Scherler wrote:
> >>>
> >>>>I added the dir specific view matcher to the location map. Will try to
> >>>>merge tomorrow the view specific stuff back to trunk.
> >>>
> >>>OK, I'm using this now, just playing to start with. Here is what I want
> >>>to do:
> >>>
> >>>I'm using the branding contracts. On the home page I just have the
> >>>branding-tagline-name contract, but on subsections (i.e.
> >>>sub-directories) I want to include a branding-tagline-tagline contract
> >>>as well. All other parts of the view remain the same.
> >>>
> >>
> >>http://marc.theaimsgroup.com/?l=forrest-dev&m=110107619329543&w=2
> >>
> >>"You can as well mix atomic parts with grouping templates.
> >><forrest:view output-format="xhtml, fo" name="intro">
> >> <forrest:hook name="intro">
> >> <forrest:nugget name="grouplogo"/>
> >> <forrest:call-template name="sports"/>
> >> </forrest:hook>
> >></forrest:view>"
> >>
> >>The nuggets/fbits are called contracts.
> >>
> >>This feature is not yet implemented but like you see IMO that will have to come pretty soon.
> >>It is easy to implement because it is just a transformation to a xinclude tag away. ;-)
> >
> >
> > I could not resist and implemented this in trunk. Please test and report
> > back.
>
> :-)) Not played with it yet, but it looks great.
>
> Question 1:
>
> Do you see a problem with having the same fallback mechanism that you
> have created for the *.ft files?
>
Actually that is possible.
...but you mean *.fv (forrest:views), or?
...or better ask you mean the mechanism I implemented with the
viewLocationmap.xml? In this case it would be viewTemplatesmap, or?
Because *.ft (forrest:templates) are match with the good old 'select
type="exit"'.
BTW the viewLocationmap.xml file should be generated or cached, because
I reckon it takes a good while to calculated in *big* projects.
> We would then be able to create a default.fv with calls to templates.
yes, that file would have ideally only calls to templates.
I needed to slightly modify the match for the *.vt (view:template) to
allow nested <forrest:call-template />.
Now we can use it like this:
****************************************
in default.fv.xml
########################################
<forrest:call-template name="header"/>
****************************************
****************************************
then in header.vt.xml
########################################
<forrest:hook name="header">
<forrest:call-template name="branding-tagline-default"/>
<forrest:contract name="nav-main"/>
</forrest:hook>
****************************************
****************************************
...and finally in branding-tagline-default.vt.xml
########################################
<forrest:contract name="branding-tagline">
<forrest:properties contract="branding-tagline">
<forrest:property name="branding-tagline-name"> new xXx seed
</forrest:property>
<forrest:property name="branding-tagline-tagline"> powered by
forrest:views
</forrest:property>
</forrest:properties>
</forrest:contract>
> Then, if we want to override the layout (i.e. add a new contract) we can
> add a new default.fv into a subdir or a file.fv for a specific file (as
> you currently have implemented). If we want to override the
> configuration of a contract within a view we would override the template
> with something like sports.ft (subdir default) or sports.index.ft (index
> file config).
>
I understood you like this:
We implement the viewTemplatesmap.xml (like the viewLocationmap.xml)
then we can use fallbacks like with forrest:views for *.vt.xml
(view:template).
default.fv.xml ({$xdocs}/subdir) this has
<forrest:call-template name=header"/>
then the viewTemplatesmap.xml would look up whether there is a
header.default.vt.xml and use it. If not it will use a fallback.
Yeah I need to implement the viewTemplatesmap.xml and then that is
possible.
> Question 2:
>
> Should we merge all this stuff together into a single document so the
> templates are defined in the *.fv file? We can then add a
> <forrest:import src="default.fv"> and override elements within that (as
> we do in XSL). This would reduce the number of files quite considerably
> and make editing by hand much easier (at least I believe so)
>
Hmm, what do you mean? I am unsure whether I understood you right. Right
now we splitting things apart for easy maintainment but on the other
hand you want to merge them again?
...but maybe that is the part I did not understood from the beginning
from nicolas mail. *Please* explain. ;-)
> Another (minor) benefit of this is that it would also remove the fixed
> naming of view files too ("default" is a little too gneeric, I think we
> will find sites with default.html so how would we ovveride the
> individual file view in this case).
>
Yeah, I thought so from the beginning that is to generic but I am
parsing the name for the "default.fv.xml" from the pipeline in the xsl,
which means as soon as we have views in the core we can easily make this
a property in the forrest.properties. ;-)
> Ross
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [views] Dir specific view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-07-07 at 22:32 +0200, Thorsten Scherler wrote:
>
>>On Thu, 2005-07-07 at 16:48 +0100, Ross Gardler wrote:
>>
>>>Thorsten Scherler wrote:
>>>
>>>>I added the dir specific view matcher to the location map. Will try to
>>>>merge tomorrow the view specific stuff back to trunk.
>>>
>>>OK, I'm using this now, just playing to start with. Here is what I want
>>>to do:
>>>
>>>I'm using the branding contracts. On the home page I just have the
>>>branding-tagline-name contract, but on subsections (i.e.
>>>sub-directories) I want to include a branding-tagline-tagline contract
>>>as well. All other parts of the view remain the same.
>>>
>>
>>http://marc.theaimsgroup.com/?l=forrest-dev&m=110107619329543&w=2
>>
>>"You can as well mix atomic parts with grouping templates.
>><forrest:view output-format="xhtml, fo" name="intro">
>> <forrest:hook name="intro">
>> <forrest:nugget name="grouplogo"/>
>> <forrest:call-template name="sports"/>
>> </forrest:hook>
>></forrest:view>"
>>
>>The nuggets/fbits are called contracts.
>>
>>This feature is not yet implemented but like you see IMO that will have to come pretty soon.
>>It is easy to implement because it is just a transformation to a xinclude tag away. ;-)
>
>
> I could not resist and implemented this in trunk. Please test and report
> back.
:-)) Not played with it yet, but it looks great.
Question 1:
Do you see a problem with having the same fallback mechanism that you
have created for the *.ft files?
We would then be able to create a default.fv with calls to templates.
Then, if we want to override the layout (i.e. add a new contract) we can
add a new default.fv into a subdir or a file.fv for a specific file (as
you currently have implemented). If we want to override the
configuration of a contract within a view we would override the template
with something like sports.ft (subdir default) or sports.index.ft (index
file config).
Question 2:
Should we merge all this stuff together into a single document so the
templates are defined in the *.fv file? We can then add a
<forrest:import src="default.fv"> and override elements within that (as
we do in XSL). This would reduce the number of files quite considerably
and make editing by hand much easier (at least I believe so)
Another (minor) benefit of this is that it would also remove the fixed
naming of view files too ("default" is a little too gneeric, I think we
will find sites with default.html so how would we ovveride the
individual file view in this case).
Ross
Re: [views] Dir specific view
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-07-07 at 22:32 +0200, Thorsten Scherler wrote:
> On Thu, 2005-07-07 at 16:48 +0100, Ross Gardler wrote:
> > Thorsten Scherler wrote:
> > > I added the dir specific view matcher to the location map. Will try to
> > > merge tomorrow the view specific stuff back to trunk.
> >
> > OK, I'm using this now, just playing to start with. Here is what I want
> > to do:
> >
> > I'm using the branding contracts. On the home page I just have the
> > branding-tagline-name contract, but on subsections (i.e.
> > sub-directories) I want to include a branding-tagline-tagline contract
> > as well. All other parts of the view remain the same.
> >
>
> http://marc.theaimsgroup.com/?l=forrest-dev&m=110107619329543&w=2
>
> "You can as well mix atomic parts with grouping templates.
> <forrest:view output-format="xhtml, fo" name="intro">
> <forrest:hook name="intro">
> <forrest:nugget name="grouplogo"/>
> <forrest:call-template name="sports"/>
> </forrest:hook>
> </forrest:view>"
>
> The nuggets/fbits are called contracts.
>
> This feature is not yet implemented but like you see IMO that will have to come pretty soon.
> It is easy to implement because it is just a transformation to a xinclude tag away. ;-)
I could not resist and implemented this in trunk. Please test and report
back.
You can group elements to a template and call it from any view. e.g.
<forrest:hook name="export-link">
<forrest:contract name="content-txt-link"/>
<forrest:contract name="content-pdf-link"/>
</forrest:hook>
can be called as
<forrest:call-template name="export-link"/>
when saved as
{project:resources}/templates/export-link.vt.xml
An example is added with -r209682.
http://svn.apache.org/viewcvs?rev=209682&view=rev
Have fun.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [views] Dir specific view
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-07-07 at 16:48 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > I added the dir specific view matcher to the location map. Will try to
> > merge tomorrow the view specific stuff back to trunk.
>
> OK, I'm using this now, just playing to start with. Here is what I want
> to do:
>
> I'm using the branding contracts. On the home page I just have the
> branding-tagline-name contract, but on subsections (i.e.
> sub-directories) I want to include a branding-tagline-tagline contract
> as well. All other parts of the view remain the same.
>
http://marc.theaimsgroup.com/?l=forrest-dev&m=110107619329543&w=2
"You can as well mix atomic parts with grouping templates.
<forrest:view output-format="xhtml, fo" name="intro">
<forrest:hook name="intro">
<forrest:nugget name="grouplogo"/>
<forrest:call-template name="sports"/>
</forrest:hook>
</forrest:view>"
The nuggets/fbits are called contracts.
This feature is not yet implemented but like you see IMO that will have to come pretty soon.
It is easy to implement because it is just a transformation to a xinclude tag away. ;-)
> I can create the effect I want by copying the default.fv from the root
> into my subdir and adding the branding contrat that I need. However,
> this causes a problem for maintenance since most of my default.fv
> content is duplicated.
>
Yes IMO the solution is to group the elements into forrest:templates
like e.g. (from the same link)
<forrest:template name="sports" output-format="fo">
<forrest:hook name="sports">
<forrest:nugget name="sportNewsAbstract"/>
</forrest:hook>
</forrest:template>
Then we can reduce the maintainment work you describe. *but* reading
http://marc.theaimsgroup.com/?l=forrest-dev&m=111989070109905&w=2 again:
"Well this is cleaner, I like that. What I am uncomfortable with is the
creation of yet another file we need to edit in order to get the page to
look the way we want it. Admittedly it is unlikely that we will need to
create all three files for many pages."
IMO there is a trade off, small overrides in external files (many files, no overhead)
or putting all in one file (one file, but a lot of overhead).
Yourself noticed now that for maintainment it makes not too much sense to have it in
one file, because you now ask:
> Is there a way of just setting the content of the
> branding-tagline-tagline contract?
>
Yes, described in
http://marc.theaimsgroup.com/?l=forrest-dev&m=111988914128794&w=2
"The forrest:properties should go in a file for their own. that would
make:
in *.fv:
<forrest:contract name="feeder"/>
and in *.prop.xml:
<forrest:properties contract="feeder">
<forrest:property name="feeder" nugget="get.nugget.feeder">
<url>/feeds/somefeed.xml</url>
</forrest:property>
</forrest:properties>
Actually here you see that it is a kind of skinconf, but especially for
the one file. That is the reason why we need to harmonize the
skinconf/forrest:properties. Where I see the skinconf as
default.prop.xml. ;-)"
The idea to have the same mechanism for default.prop.xml and default.fv.xml (I reckon I should drop the fancy extension) ;-)
[OT] One could use as well default.xml as kind of file not found fallback. of course as well on a per-dir basis. ;-)
> If not how would you suggest I go about making this happen?
We need to harmonize the skinconf.xml that it can become the
default.prop.xml. Then we need to add all matches for *.prop.xml into
the view plugin and add it to the aggregation.
BTW http://marc.theaimsgroup.com/?l=forrest-dev&m=111989070109905&w=2
"[ASIDE] I think we need to create a more generic contract instead of
this feeder one, it looks exactly the same and behaves exactly the same,
but it is called "embed" or something like that. This can be used to
embed any content within a view based page - this gives us a portal."
*hust*businessHelper*hust* ;-)
I was at a client yesterday and he showed me his own portlet implementation for cocoon (no java spec. one, but
more a modified cocoon portal one) and I showed him views.
Guess what, we developed similar solutions without knowing from each other.
Yes views gives us a portal. Even right now, but I agree we need a more generic contract. My client used
*.xmap as businessHelper that where linked with a portlet.
I mean we can allow each contract to resolve the model trough a contract specific sitemap. Since yesterday
I cannot stop thinking about it. It follows the KISS approach which rocks. :)
José Ignacio the head dev from this client even donated me some code that I can use for views. :) Like I said
we solved the same problems. The trickiest one was to include dynamically xsl in the final xsl.
I solved it with plain xsl and a couple of pipes (last call: getStylesheet.*.**)
he with a custom generator.
I may use it when we add view to the core to refactor some code.
...but Antonio once said to me what I need is a transformer
and not a generator ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [views] Dir specific view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> I added the dir specific view matcher to the location map. Will try to
> merge tomorrow the view specific stuff back to trunk.
OK, I'm using this now, just playing to start with. Here is what I want
to do:
I'm using the branding contracts. On the home page I just have the
branding-tagline-name contract, but on subsections (i.e.
sub-directories) I want to include a branding-tagline-tagline contract
as well. All other parts of the view remain the same.
I can create the effect I want by copying the default.fv from the root
into my subdir and adding the branding contrat that I need. However,
this causes a problem for maintenance since most of my default.fv
content is duplicated.
Is there a way of just setting the content of the
branding-tagline-tagline contract?
If not how would you suggest I go about making this happen?
Ross