Re: On $content$ again
+1 2008/8/18 Hugo Palma <[EMAIL PROTECTED]> > +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 <[EMAIL PROTECTED]> >> >> >> >>> 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 & >>> 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 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. >>> >>> >>> ... stuff stuff stuff. >>> THe content that I care for >>> ... more stuff stuff stuff ... >>> >>> >>> >>> whereas now, the two are very much far apart and much more difficult to >>> distinguish from the "other stuff", e.g. >>> >>> >>> stuff stuff stuff ... >>> the content that I care for >>> ... more stuff stuff... stuff ... >>> >>> >>> 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 tag with t:type="layout" and wrap the $content$ area with >>> name="body">...page content Simple. Inside the layout >>> you >>> >>> use instead of and that's all (there "body" is the component parameter). Like this: Layout.tml ... ... .. Page1.html: ... ... Foo, bar baz .. -- WBR, Ivan S. Dubrov
Re: On $content$ again
+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 <[EMAIL PROTECTED]> 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 & 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 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. ... stuff stuff stuff. THe content that I care for ... more stuff stuff stuff ... whereas now, the two are very much far apart and much more difficult to distinguish from the "other stuff", e.g. stuff stuff stuff ... the content that I care for ... more stuff stuff... stuff ... 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 tag with t:type="layout" and wrap the $content$ area with ...page content Simple. Inside the layout you use instead of and that's all (there "body" is the component parameter). Like this: Layout.tml ... ... .. Page1.html: ... ... Foo, bar baz .. -- WBR, Ivan S. Dubrov - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: On $content$ again
+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 <[EMAIL PROTECTED]> > 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 & > 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 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. > > > ... stuff stuff stuff. > THe content that I care for > ... more stuff stuff stuff ... > > > > whereas now, the two are very much far apart and much more difficult to > distinguish from the "other stuff", e.g. > > > stuff stuff stuff ... > the content that I care for > ... more stuff stuff... stuff ... > > > 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 tag with > > t:type="layout" and wrap the $content$ area with > name="body">...page content Simple. Inside the layout > you > > use instead of and that's all (there > > "body" is the component parameter). > > > > Like this: > > > > Layout.tml > > > > ... > > > >... > > > >.. > > > > > > > > Page1.html: > > > > > > ... > > > >... > >Foo, bar baz > > > > > >.. > > > > > > > > -- > > WBR, > > Ivan S. Dubrov > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: On $content$ again
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 & 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 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. ... stuff stuff stuff. THe content that I care for ... more stuff stuff stuff ... whereas now, the two are very much far apart and much more difficult to distinguish from the "other stuff", e.g. stuff stuff stuff ... the content that I care for ... more stuff stuff... stuff ... 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 tag with > t:type="layout" and wrap the $content$ area with name="body">...page content Simple. Inside the layout you > use instead of and that's all (there > "body" is the component parameter). > > Like this: > > Layout.tml > > ... > >... > >.. > > > > Page1.html: > > > ... > >... >Foo, bar baz > > >.. > > > > -- > WBR, > Ivan S. Dubrov > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: On $content$ again
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 tag with t:type="layout" and wrap the $content$ area with name="body">...page content Simple. Inside the layout you use instead of and that's all (there "body" is the component parameter). Like this: Layout.tml ... ... .. Page1.html: ... ... Foo, bar baz .. -- WBR, Ivan S. Dubrov - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 ... ... .. Page1.html would typically come as a full html doc, now, I only care for the stuff inside of 'content' div. ... ... Foo, bar baz .. If there were a $content$, I'd do something like this in Page1: ... ... Foo, bar baz .. Now, since there is no $content$, I have to either totally gut the previewability of the template: Foo, bar baz Or, I have to do something like this : ... ... Foo, bar baz .. 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
