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
