Ivan,
thank you for offering your suggestion, indeed the solution you propose
for this particular case is straightforward enough and solves the problem.
I guess the reason that I was bringing this up for consideration (despite
it being discussed in the past), is that the lack of $content$ equivalent
functionality introduced a couple of not very desirable things into my
setup:
1. In order to solve this problem, I had to introduce an "unnecessary"
element into my layout, namely the <t:parameter /> & <t:delegate />
elements, in order to account for the possibility that the user might want
to have a previewable template. In order for a "client" page to use my
layout component, it not only need to know about the layout component, but
also need to know that "the content" needs to be included in a particularly
named element. One could certainly say that this is the "API" for using the
layout component. The thing is that if I go this route, all pages that want
to use the layout will have to have the extra <t:parameter /> included, and
that doesn't seem very clean.
2. I had to declare the component at the top of the page, making it wrap
around a whole bunch of things that I don't care for (although, from a
different point of view, it indeed makes sense to declare the t:layout
component at the top as it affects the whole page). So, while previously,
the declaration (e.g. where I specify the t:layout) and providing the
content for the component (e.g. seeing what actually ends up in the
"content" area of my output) were very close together e.g.
<html ...>
... stuff stuff stuff.....
<t:layout > THe content that I care for </t:layout>
... more stuff stuff stuff ...
</html>
whereas now, the two are very much far apart and much more difficult to
distinguish from the "other stuff", e.g.
<html t:type="layout">
.... stuff stuff stuff ...
<t:parameter> the content that I care for </t:parameter>
... more stuff.... stuff... stuff ...
</html>
So, in summary I guess I'm bringing up the more conceptual problem of how
the lack of the equivalent of $content$ just makes two very common usages
(e.g. having a layout component, having a previewable page based on that
content) just a little harder to get started with. When you add to that the
fact that most "layout" component examples in T5 do not include the
solution
you propose (e.g. most use t:body), it just adds a little bit of extra
complexity (which is generally against what I understand is one of the main
goals of T5).
In one of the previous posts it was suggested that patching the parser was
the way to add $content$ equivalent functionality. Would that be a
desirable
feature for other members (or is it just all in my head) ? Are there are
any
reasons adding such a feature would be unwanted ? Are there any special
issues that I need to be aware of in implementing this ?
Thanks,
Alex Kotchnev
On Sat, Aug 16, 2008 at 11:31 PM, Ivan Dubrov <[EMAIL PROTECTED]> wrote:
Alex Kotchnev wrote:
I also found this solution :
http://www.nabble.com/Re-%3A-Re-%3A-T5%3A-Layout-question-to16448904.html#a16448904
,
but life just becomes a little uglier with it. I see that we're
jumping
through these hoops to prevent template previewability and so if it
becomes
too much of a hassle to deal with I can scrap previewability. However,
it's
such a pity when it was nice and elegant in T4, and not it's a little
worse.
What are the problems with the last option? You just mark <html> tag with
t:type="layout" and wrap the $content$ area with <t:parameter
name="body">...page content...</t:parameter>. Simple. Inside the layout
you
use <t:delegate t:to="body"/> instead of <t:body/> and that's all (there
"body" is the component parameter).
Like this:
Layout.tml
<html>
<head> ... </head>
<body>
<div id="header"> ...</div>
<div id="content"> <t:delegate t:to="body" /> </div>
<div id="footer"> .. </div>
</body>
</html>
Page1.html:
<html t:type="layout">
<head> ... </head>
<body>
<div id="header"> ...</div>
<div id="content"><t:parameter name="body"> Foo, bar baz
</t:parameter></div>
<div id="footer"> .. </div>
</body>
</html>
--
WBR,
Ivan S. Dubrov
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
