You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Filip S. Adamsen" <fi...@stubkjaer-adamsen.dk> on 2004/06/08 21:29:29 UTC
Page specification inheritance
I have been wondering about this for a while: Could it be possible for one
page specification to extend another? Example .page files:
FooParent.page (mind the abstract-attribute in the page specification):
[prologue omitted]
<page-specification class="FooParent" abstract="true">
<property-specification name="item" persistent="yes" type="FooItem"/>
<context-asset name="fooStylesheet" path="assets/stylesheets/foo.css"/>
</page-specification>
FooChildA.page (mind the extends attribute in the page specification):
[prologue omitted]
<page-specification class="FooChildA" extends="FooParent">
[custom properties etc.]
</page-specification>
FooChildB.page (mind the extends attribute in the page specification):
[prologue omitted]
<page-specification class="FooChildB" extends="FooParent">
[custom properties etc.]
</page-specification>
I think this would be a valuable feature for Tapestry - or I might be wrong?
-Filip S. Adamsen
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Page specification inheritance
Posted by "Christopher M. DeBracy" <ch...@debracy.net>.
Thanks!
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Wednesday, June 09, 2004 1:00 PM
> To: Tapestry users
> Subject: Re: Page specification inheritance
>
>
> Sorry, not much time to detail this but I'm sure I've posted
> a bit on
> it before. Basically you register it as an extension:
>
> http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/
> configuration.extensions.html
>
> If a template is not found in the normal path (in other words, don't
> have .html files for the templates you want dynamic, not by
> exact name
> you use, at least), then the delegate is asked to return it.
>
> Erik
>
>
> On Jun 9, 2004, at 1:48 PM, Christopher M. DeBracy wrote:
>
> > If I implement the ITemplateSourceDelegate, where does it get wired
> > in? My
> > Border.page already declares a class for handling the menu
> items and
> > that
> > class extends BaseComponent.
> >
> > Additionally, I only need one .page to use this delegate, not all.
> >
> > Thanks,
> >
> > Chris
> >
> >> -----Original Message-----
> >> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> >> Sent: Tuesday, June 08, 2004 6:58 PM
> >> To: Tapestry users
> >> Subject: Re: Page specification inheritance
> >>
> >>
> >> On Jun 8, 2004, at 4:40 PM, Christopher M. DeBracy wrote:
> >>> I'd hate to lose the benefits of caching and I'd prefer to
> >> keep things
> >>> simple.
> >>
> >> I didn't mean you'd lose the benefits of caching... I
> meant that with
> >> ITemplateSourceDelegate, the outputted template is cached
> and not as
> >> dynamic as one would like. (I think)
> >>
> >>> I originally tried using @Conditional within my Border.html, but
> >>> Tapestry didn't like the duplicate references to my
> component id's.
> >> I may try
> >>> another
> >>> tack by playing with Border.html directly.
> >>
> >> duplicate references? that sounds easily fixable. what are the
> >> details of that?
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page specification inheritance
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Sorry, not much time to detail this but I'm sure I've posted a bit on
it before. Basically you register it as an extension:
http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/
configuration.extensions.html
If a template is not found in the normal path (in other words, don't
have .html files for the templates you want dynamic, not by exact name
you use, at least), then the delegate is asked to return it.
Erik
On Jun 9, 2004, at 1:48 PM, Christopher M. DeBracy wrote:
> If I implement the ITemplateSourceDelegate, where does it get wired
> in? My
> Border.page already declares a class for handling the menu items and
> that
> class extends BaseComponent.
>
> Additionally, I only need one .page to use this delegate, not all.
>
> Thanks,
>
> Chris
>
>> -----Original Message-----
>> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
>> Sent: Tuesday, June 08, 2004 6:58 PM
>> To: Tapestry users
>> Subject: Re: Page specification inheritance
>>
>>
>> On Jun 8, 2004, at 4:40 PM, Christopher M. DeBracy wrote:
>>> I'd hate to lose the benefits of caching and I'd prefer to
>> keep things
>>> simple.
>>
>> I didn't mean you'd lose the benefits of caching... I meant that with
>> ITemplateSourceDelegate, the outputted template is cached and not as
>> dynamic as one would like. (I think)
>>
>>> I originally tried using @Conditional within my Border.html, but
>>> Tapestry
>>> didn't like the duplicate references to my component id's.
>> I may try
>>> another
>>> tack by playing with Border.html directly.
>>
>> duplicate references? that sounds easily fixable. what are the
>> details of that?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Page specification inheritance
Posted by "Christopher M. DeBracy" <ch...@debracy.net>.
If I implement the ITemplateSourceDelegate, where does it get wired in? My
Border.page already declares a class for handling the menu items and that
class extends BaseComponent.
Additionally, I only need one .page to use this delegate, not all.
Thanks,
Chris
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Tuesday, June 08, 2004 6:58 PM
> To: Tapestry users
> Subject: Re: Page specification inheritance
>
>
> On Jun 8, 2004, at 4:40 PM, Christopher M. DeBracy wrote:
> > I'd hate to lose the benefits of caching and I'd prefer to
> keep things
> > simple.
>
> I didn't mean you'd lose the benefits of caching... I meant that with
> ITemplateSourceDelegate, the outputted template is cached and not as
> dynamic as one would like. (I think)
>
> > I originally tried using @Conditional within my Border.html, but
> > Tapestry
> > didn't like the duplicate references to my component id's.
> I may try
> > another
> > tack by playing with Border.html directly.
>
> duplicate references? that sounds easily fixable. what are the
> details of that?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page specification inheritance
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jun 8, 2004, at 4:40 PM, Christopher M. DeBracy wrote:
> I'd hate to lose the benefits of caching and I'd prefer to keep things
> simple.
I didn't mean you'd lose the benefits of caching... I meant that with
ITemplateSourceDelegate, the outputted template is cached and not as
dynamic as one would like. (I think)
> I originally tried using @Conditional within my Border.html, but
> Tapestry
> didn't like the duplicate references to my component id's. I may try
> another
> tack by playing with Border.html directly.
duplicate references? that sounds easily fixable. what are the
details of that?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Page specification inheritance
Posted by "Christopher M. DeBracy" <ch...@debracy.net>.
I'd hate to lose the benefits of caching and I'd prefer to keep things
simple.
I originally tried using @Conditional within my Border.html, but Tapestry
didn't like the duplicate references to my component id's. I may try another
tack by playing with Border.html directly.
Chris
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Tuesday, June 08, 2004 3:31 PM
> To: Tapestry users
> Subject: Re: Page specification inheritance
>
>
> At a low-level, by implementing your own pieces to the BaseEngine
> puzzle, you can control where specifications and templates
> come from.
> It's highly dynamic, but also highly complex to get right.
> But simply
> controlling where templates come from could be done using the
> ITemplateSourceDelegate extension feature (check the archives for
> pointers to more info) - caveat: caching may be a problem though.
> There is more control above this delegate option, but more
> complicated.
> I've tinkered a little in this space, but not currently
> using any of
> the prototypes I hacked.
>
> Erik
>
>
> On Jun 8, 2004, at 4:21 PM, Christopher M. DeBracy wrote:
>
> > What I first tried was the following:
> >
> > <context-asset name="$template">
> > <binding name="path" expression="templateName"/>
> > </context-asset>
> >
> > Of course, path is #REQUIRED so that didn't work. Even if
> it had, seem
> > like
> > it still wants the .html name to match the .page file.
> >
> > I like the way Tiles allows you to extend from another
> definition. If
> > Tapestry could do the same, I think it would be great.
> >
> >> -----Original Message-----
> >> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> >> Sent: Tuesday, June 08, 2004 2:54 PM
> >> To: Tapestry users
> >> Subject: Re: Page specification inheritance
> >>
> >>
> >> I certainly wish this was possible. Just today I "extended" the
> >> Upload component by copy/pasting the .jwc and .java files (to add
> >> validation on an allowable set of mime types).
> >>
> >> Erik
> >>
> >>
> >> On Jun 8, 2004, at 3:29 PM, Filip S. Adamsen wrote:
> >>
> >>> I have been wondering about this for a while: Could it be
> >> possible for
> >>> one
> >>> page specification to extend another? Example .page files:
> >>>
> >>>
> >>> FooParent.page (mind the abstract-attribute in the page
> >>> specification):
> >>>
> >>> [prologue omitted]
> >>>
> >>> <page-specification class="FooParent" abstract="true">
> >>> <property-specification name="item" persistent="yes"
> >>> type="FooItem"/>
> >>> <context-asset name="fooStylesheet"
> >>> path="assets/stylesheets/foo.css"/>
> >>> </page-specification>
> >>>
> >>>
> >>> FooChildA.page (mind the extends attribute in the page
> >> specification):
> >>>
> >>> [prologue omitted]
> >>>
> >>> <page-specification class="FooChildA" extends="FooParent">
> >>> [custom properties etc.]
> >>> </page-specification>
> >>>
> >>>
> >>> FooChildB.page (mind the extends attribute in the page
> >> specification):
> >>>
> >>> [prologue omitted]
> >>>
> >>> <page-specification class="FooChildB" extends="FooParent">
> >>> [custom properties etc.]
> >>> </page-specification>
> >>>
> >>>
> >>> I think this would be a valuable feature for Tapestry - or
> >> I might be
> >>> wrong?
> >>>
> >>> -Filip S. Adamsen
> >>>
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page specification inheritance
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
At a low-level, by implementing your own pieces to the BaseEngine
puzzle, you can control where specifications and templates come from.
It's highly dynamic, but also highly complex to get right. But simply
controlling where templates come from could be done using the
ITemplateSourceDelegate extension feature (check the archives for
pointers to more info) - caveat: caching may be a problem though.
There is more control above this delegate option, but more complicated.
I've tinkered a little in this space, but not currently using any of
the prototypes I hacked.
Erik
On Jun 8, 2004, at 4:21 PM, Christopher M. DeBracy wrote:
> What I first tried was the following:
>
> <context-asset name="$template">
> <binding name="path" expression="templateName"/>
> </context-asset>
>
> Of course, path is #REQUIRED so that didn't work. Even if it had, seem
> like
> it still wants the .html name to match the .page file.
>
> I like the way Tiles allows you to extend from another definition. If
> Tapestry could do the same, I think it would be great.
>
>> -----Original Message-----
>> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
>> Sent: Tuesday, June 08, 2004 2:54 PM
>> To: Tapestry users
>> Subject: Re: Page specification inheritance
>>
>>
>> I certainly wish this was possible. Just today I "extended"
>> the Upload
>> component by copy/pasting the .jwc and .java files (to add validation
>> on an allowable set of mime types).
>>
>> Erik
>>
>>
>> On Jun 8, 2004, at 3:29 PM, Filip S. Adamsen wrote:
>>
>>> I have been wondering about this for a while: Could it be
>> possible for
>>> one
>>> page specification to extend another? Example .page files:
>>>
>>>
>>> FooParent.page (mind the abstract-attribute in the page
>>> specification):
>>>
>>> [prologue omitted]
>>>
>>> <page-specification class="FooParent" abstract="true">
>>> <property-specification name="item" persistent="yes"
>>> type="FooItem"/>
>>> <context-asset name="fooStylesheet"
>>> path="assets/stylesheets/foo.css"/>
>>> </page-specification>
>>>
>>>
>>> FooChildA.page (mind the extends attribute in the page
>> specification):
>>>
>>> [prologue omitted]
>>>
>>> <page-specification class="FooChildA" extends="FooParent">
>>> [custom properties etc.]
>>> </page-specification>
>>>
>>>
>>> FooChildB.page (mind the extends attribute in the page
>> specification):
>>>
>>> [prologue omitted]
>>>
>>> <page-specification class="FooChildB" extends="FooParent">
>>> [custom properties etc.]
>>> </page-specification>
>>>
>>>
>>> I think this would be a valuable feature for Tapestry - or
>> I might be
>>> wrong?
>>>
>>> -Filip S. Adamsen
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Page specification inheritance
Posted by "Christopher M. DeBracy" <ch...@debracy.net>.
What I first tried was the following:
<context-asset name="$template">
<binding name="path" expression="templateName"/>
</context-asset>
Of course, path is #REQUIRED so that didn't work. Even if it had, seem like
it still wants the .html name to match the .page file.
I like the way Tiles allows you to extend from another definition. If
Tapestry could do the same, I think it would be great.
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Tuesday, June 08, 2004 2:54 PM
> To: Tapestry users
> Subject: Re: Page specification inheritance
>
>
> I certainly wish this was possible. Just today I "extended"
> the Upload
> component by copy/pasting the .jwc and .java files (to add validation
> on an allowable set of mime types).
>
> Erik
>
>
> On Jun 8, 2004, at 3:29 PM, Filip S. Adamsen wrote:
>
> > I have been wondering about this for a while: Could it be
> possible for
> > one
> > page specification to extend another? Example .page files:
> >
> >
> > FooParent.page (mind the abstract-attribute in the page
> > specification):
> >
> > [prologue omitted]
> >
> > <page-specification class="FooParent" abstract="true">
> > <property-specification name="item" persistent="yes"
> > type="FooItem"/>
> > <context-asset name="fooStylesheet"
> > path="assets/stylesheets/foo.css"/>
> > </page-specification>
> >
> >
> > FooChildA.page (mind the extends attribute in the page
> specification):
> >
> > [prologue omitted]
> >
> > <page-specification class="FooChildA" extends="FooParent">
> > [custom properties etc.]
> > </page-specification>
> >
> >
> > FooChildB.page (mind the extends attribute in the page
> specification):
> >
> > [prologue omitted]
> >
> > <page-specification class="FooChildB" extends="FooParent">
> > [custom properties etc.]
> > </page-specification>
> >
> >
> > I think this would be a valuable feature for Tapestry - or
> I might be
> > wrong?
> >
> > -Filip S. Adamsen
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Page specification inheritance
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I certainly wish this was possible. Just today I "extended" the Upload
component by copy/pasting the .jwc and .java files (to add validation
on an allowable set of mime types).
Erik
On Jun 8, 2004, at 3:29 PM, Filip S. Adamsen wrote:
> I have been wondering about this for a while: Could it be possible for
> one
> page specification to extend another? Example .page files:
>
>
> FooParent.page (mind the abstract-attribute in the page specification):
>
> [prologue omitted]
>
> <page-specification class="FooParent" abstract="true">
> <property-specification name="item" persistent="yes"
> type="FooItem"/>
> <context-asset name="fooStylesheet"
> path="assets/stylesheets/foo.css"/>
> </page-specification>
>
>
> FooChildA.page (mind the extends attribute in the page specification):
>
> [prologue omitted]
>
> <page-specification class="FooChildA" extends="FooParent">
> [custom properties etc.]
> </page-specification>
>
>
> FooChildB.page (mind the extends attribute in the page specification):
>
> [prologue omitted]
>
> <page-specification class="FooChildB" extends="FooParent">
> [custom properties etc.]
> </page-specification>
>
>
> I think this would be a valuable feature for Tapestry - or I might be
> wrong?
>
> -Filip S. Adamsen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org