You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Alex Kotchnev <ak...@gmail.com> on 2008/08/16 09:12:55 UTC
On $content$ again
I know that this issue was discussed in the past (e.g.
http://www.nabble.com/Equivalent-of-jwcid%3D%22%24content%24%22-in-T5-td17581189s302.html#a17581189,
http://www.nabble.com/T5-equivalent-of-%24content%24-td9138619s302.html#a9138619)
and the conclusion was there currently is no equivalent of jwcid="$content$"
from T4. Now, I can understand how the proposed workarounds would work, but
I most definitely like being able to annotate a fully working/previewable
html page, and make it work in Tapestry without having to gut pretty much
the whole thing.
Now, here's what I do :
Layout component template (it's the regular stuff) , e.g. :
Layout.html
<html>
<head> ... </head>
<body>
<div id="header"> ...</div>
<div id="content"> <t:body /> </div>
<div id="footer"> .. </div>
</body>
</html>
Page1.html would typically come as a full html doc, now, I only care for the
stuff inside of 'content' div.
<html>
<head> ... </head>
<body>
<div id="header"> ...</div>
<div id="content"> Foo, bar baz </div>
<div id="footer"> .. </div>
</body>
</html>
If there were a $content$, I'd do something like this in Page1:
<html>
<head> ... </head>
<body>
<div id="header"> ...</div>
<div id="content" t:type="$content$">
<t:layout > Foo, bar baz </t:layout>
</div>
<div id="footer"> .. </div>
</body>
</html>
Now, since there is no $content$, I have to either totally gut the
previewability of the template:
<t:layout > Foo, bar baz </t:layout>
Or, I have to do something like this :
<html t:type="layout">
<head t:type="remove"> ... </head>
<body t:type="container">
<div id="header" t:type="remove"> ...</div>
<div id="content" t:type="container">
Foo, bar baz
</div>
<div id="footer" t:type="remove"> .. </div>
</body>
</html>
Now, let's admit it, the next to last version is definitely most concise,
but kills one of the huge Tapestry perks : previewability. The last version
should work (I haven't tried it yet), but man, it's becomes cluttered w/
these "remove" and "container" elements that just clutter things (and mind
you, this is a simple layout, if the layout is more complicated it gets even
uglier).
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.
I also see that there is an idea to have t:container serve almost like
$content$ by discarding its parent..
So, I wonder, would there be any possibility of being able to restore the
existence of the $content$ component ? Is there something in T5 that makes
it impossible technically ? Or is there a phylosophical objection to its
existence in the first place ? Any comments ?
Thanks,
Alex Kotchnev
Re: On $content$ again
Posted by Jun Tsai <ju...@gmail.com>.
+1
2008/8/18 Hugo Palma <hu...@gmail.com>
> +1
>
> T5 is all about making things easy. I would say that having an equivalent
> to $content$ would be a step in the right direction.
> Maybe issue TAPESTRY-1710 should be reopened ?
>
>
> Onno Scheffers wrote:
>
>> +1
>>
>> Having $content$ is much better IMHO. I'm using the other approach
>> currently
>> as a work-around, but it doesn't feel as clean or as easy as having
>> $content$. I'm adding a commentblock to the elements to make clear what is
>> happening there so future developers on the project don't get confused.
>>
>> regards,
>>
>> Onno
>>
>>
>> 2008/8/18 Alex Kotchnev <ak...@gmail.com>
>>
>>
>>
>>> 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 <wf...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
--
regards,
Jun Tsai
Re: On $content$ again
Posted by Hugo Palma <hu...@gmail.com>.
+1
T5 is all about making things easy. I would say that having an
equivalent to $content$ would be a step in the right direction.
Maybe issue TAPESTRY-1710 should be reopened ?
Onno Scheffers wrote:
> +1
>
> Having $content$ is much better IMHO. I'm using the other approach currently
> as a work-around, but it doesn't feel as clean or as easy as having
> $content$. I'm adding a commentblock to the elements to make clear what is
> happening there so future developers on the project don't get confused.
>
> regards,
>
> Onno
>
>
> 2008/8/18 Alex Kotchnev <ak...@gmail.com>
>
>
>> 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 <wf...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>
>
Re: On $content$ again
Posted by Onno Scheffers <on...@piraya.nl>.
+1
Having $content$ is much better IMHO. I'm using the other approach currently
as a work-around, but it doesn't feel as clean or as easy as having
$content$. I'm adding a commentblock to the elements to make clear what is
happening there so future developers on the project don't get confused.
regards,
Onno
2008/8/18 Alex Kotchnev <ak...@gmail.com>
> 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 <wf...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: On $content$ again
Posted by Alex Kotchnev <ak...@gmail.com>.
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 <wf...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: On $content$ again
Posted by Ivan Dubrov <wf...@gmail.com>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org