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
