You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by John Meredith <ps...@t-online.de> on 2003/08/03 23:54:12 UTC
Re: Needed Customised Images for Paging Mechanism for
table Component
Hang on ... I think I've found a problem ... give me a couple of minutes
:-|
- John
On Sun, 2003-08-03 at 23:40, Harish Krishnaswamy wrote:
> Is it possible to post the code?
>
> -Harish
>
> John Meredith wrote:
>
> >Cool. Just got this working, including caching it seems, although I'll
> >need to do more tests just to make sure. I love working with Tapestry
> >:-)
> >
> >If anyone's interested I'll post some more info.
> >
> > - John
> >
> >On Sun, 2003-08-03 at 14:01, John Meredith wrote:
> >
> >
> >>Hi,
> >>
> >>As we've just been given the go-ahead to use Tapestry in our next
> >>project, I've been thinking about dynamic template specification a
> >>little more as we'll need to implement something for this to enable
> >>syndication (with custom templates). Our requirement is not, however,
> >>the ability to specify the template per component, but rather globally.
> >>
> >>I'd be inclined to implement the functionality in a manor analogous to
> >>the way the Locale is handled at the moment (i.e. in the Engine). We'd
> >>need a new property say TemplateClass (not related to CSS at all) which
> >>could also be stored (as is the Locale) via a cookie client-side.
> >>
> >>The advantages I see in this approach (someone please correct me if I'm
> >>wrong) is it would involve a relatively minimal change to the engine,
> >>but would require some work in DefaultTemplateSource such that templates
> >>are cached with along with their locale and their templateClass.
> >>
> >>The thing that one would need to agree on would be the template naming
> >>conventions. I guess something like the way locale is handled presently
> >>ie. pagename_en.html. I guess using something like
> >>pagename_templategroupid_en.html would be possible, but it's not very
> >>nice.
> >>
> >>Obviously, this would not allow you to specify a templateGroup per
> >>component, but neither can you specify the locale of a component at
> >>present (nor can I see a reason why you would want to).
> >>
> >>Can anyone see any problems with this approach? (I'm happy to be told
> >>I'm a complete banana :-)
> >>
> >> John
> >>
> >>On Fri, 2003-08-01 at 19:41, Stefano Bagnara wrote:
> >>
> >>
> >>>>>What do you mean with "embeded component ids" ?
> >>>>>
> >>>>>
> >>>>>
> >>>>When templates are parsed components are identified and
> >>>>matched with the
> >>>>specification by their IDs. So if the template is going to
> >>>>be decoupled
> >>>>from the specification, there has to be a way of mapping the
> >>>>component
> >>>>in the template with that in the specification, right?
> >>>>
> >>>>
> >>>This could be done in the page template or in the component
> >>>specification:
> >>>
> >>><span jcwid="componentid@componentns:componenttype"
> >>>jcwtemplate="differenttemplatename" />
> >>>
> >>>While you include a component you could declare a different template.
> >>>The componentresolver is called everytime a similar line is found (i
> >>>think) and if it loads 2 different components for
> >>>"componentid@componentns:componenttype" and
> >>>"componentid@componentns:componenttype" with jcwtemplate =
> >>>"differenttemplatename" and the templateresolver use the
> >>>"differenttemplatename" to find a different template at loadtime then it
> >>>should work.
> >>>
> >>>Currently there is not templatepath specification: the resolver "assume"
> >>>that the template is named like the component has an html extension
> >>>(this is a parameter for tapestry) and it is in the same directory
> >>>(maybe).
> >>>
> >>>Think at <span
> >>>jcwid="componentid@componentns:componenttype|differenttemplatename" />
> >>>if you want better compatibility with the current tapestry
> >>>engine/resolvers.
> >>>
> >>>Please note I don't like the form
> >>>componentid@componentns:componenttype|differenttemplatename but it is
> >>>only an example.
> >>>
> >>>-b-
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>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
--
John Meredith <ps...@t-online.de>
Re: Needed Customised Images for Paging Mechanism
for table Component
Posted by John Meredith <ps...@t-online.de>.
Hi,
Seems I was a little premature - I'm stuck as well.
I've posted the sources at http://www.psynix.com/tapestry/ in case your
interested.
Basically, what I've tried to do is add another key (in this case the
Skin id) to the MultiKey in both PageSource and SkinnedTemplateSource
(both of which are very slightly modified copies from the Tapestry
framework pageload/PageSource and engine/DefaultTemplateSource
respectively).
Caching of the templates seems to work ok, however ... when it comes to
caching the Pages there are problems in that a page is only associated
with one template (which is the default I know). I'll be b$%^#^%d if I
can find out why, when loading the page from the pool in PageSource with
the extra Skin id key, it still only loads the first template (which may
have been skinned and/or localised on first call). Does anyone have any
idea why that would be?
Again, bear in mind that I'm no guru (in either Tapestry or Java) - so
feel free to ignore :-)
- John
On Sun, 2003-08-03 at 23:55, Harish Krishnaswamy wrote:
> No hurry, whenever you can would be great.
>
> Thanks
> Harish
>
> John Meredith wrote:
>
> >Hang on ... I think I've found a problem ... give me a couple of minutes
> >:-|
> >
> > - John
> >
> >On Sun, 2003-08-03 at 23:40, Harish Krishnaswamy wrote:
> >
> >
> >>Is it possible to post the code?
> >>
> >>-Harish
> >>
> >>John Meredith wrote:
> >>
> >>
> >>
> >>>Cool. Just got this working, including caching it seems, although I'll
> >>>need to do more tests just to make sure. I love working with Tapestry
> >>>:-)
> >>>
> >>>If anyone's interested I'll post some more info.
> >>>
> >>> - John
> >>>
> >>>On Sun, 2003-08-03 at 14:01, John Meredith wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>As we've just been given the go-ahead to use Tapestry in our next
> >>>>project, I've been thinking about dynamic template specification a
> >>>>little more as we'll need to implement something for this to enable
> >>>>syndication (with custom templates). Our requirement is not, however,
> >>>>the ability to specify the template per component, but rather globally.
> >>>>
> >>>>I'd be inclined to implement the functionality in a manor analogous to
> >>>>the way the Locale is handled at the moment (i.e. in the Engine). We'd
> >>>>need a new property say TemplateClass (not related to CSS at all) which
> >>>>could also be stored (as is the Locale) via a cookie client-side.
> >>>>
> >>>>The advantages I see in this approach (someone please correct me if I'm
> >>>>wrong) is it would involve a relatively minimal change to the engine,
> >>>>but would require some work in DefaultTemplateSource such that templates
> >>>>are cached with along with their locale and their templateClass.
> >>>>
> >>>>The thing that one would need to agree on would be the template naming
> >>>>conventions. I guess something like the way locale is handled presently
> >>>>ie. pagename_en.html. I guess using something like
> >>>>pagename_templategroupid_en.html would be possible, but it's not very
> >>>>nice.
> >>>>
> >>>>Obviously, this would not allow you to specify a templateGroup per
> >>>>component, but neither can you specify the locale of a component at
> >>>>present (nor can I see a reason why you would want to).
> >>>>
> >>>>Can anyone see any problems with this approach? (I'm happy to be told
> >>>>I'm a complete banana :-)
> >>>>
> >>>> John
> >>>>
> >>>>On Fri, 2003-08-01 at 19:41, Stefano Bagnara wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>What do you mean with "embeded component ids" ?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>When templates are parsed components are identified and
> >>>>>>matched with the
> >>>>>>specification by their IDs. So if the template is going to
> >>>>>>be decoupled
> >>>>>>
> >>>>>>
> >>>>>>from the specification, there has to be a way of mapping the
> >>>>>
> >>>>>
> >>>>>>component
> >>>>>>in the template with that in the specification, right?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>This could be done in the page template or in the component
> >>>>>specification:
> >>>>>
> >>>>><span jcwid="componentid@componentns:componenttype"
> >>>>>jcwtemplate="differenttemplatename" />
> >>>>>
> >>>>>While you include a component you could declare a different template.
> >>>>>The componentresolver is called everytime a similar line is found (i
> >>>>>think) and if it loads 2 different components for
> >>>>>"componentid@componentns:componenttype" and
> >>>>>"componentid@componentns:componenttype" with jcwtemplate =
> >>>>>"differenttemplatename" and the templateresolver use the
> >>>>>"differenttemplatename" to find a different template at loadtime then it
> >>>>>should work.
> >>>>>
> >>>>>Currently there is not templatepath specification: the resolver "assume"
> >>>>>that the template is named like the component has an html extension
> >>>>>(this is a parameter for tapestry) and it is in the same directory
> >>>>>(maybe).
> >>>>>
> >>>>>Think at <span
> >>>>>jcwid="componentid@componentns:componenttype|differenttemplatename" />
> >>>>>if you want better compatibility with the current tapestry
> >>>>>engine/resolvers.
> >>>>>
> >>>>>Please note I don't like the form
> >>>>>componentid@componentns:componenttype|differenttemplatename but it is
> >>>>>only an example.
> >>>>>
> >>>>>-b-
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>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
--
John Meredith <ps...@t-online.de>
Re: Needed Customised Images for Paging Mechanism for table Component
Posted by Harish Krishnaswamy <hk...@comcast.net>.
No hurry, whenever you can would be great.
Thanks
Harish
John Meredith wrote:
>Hang on ... I think I've found a problem ... give me a couple of minutes
>:-|
>
> - John
>
>On Sun, 2003-08-03 at 23:40, Harish Krishnaswamy wrote:
>
>
>>Is it possible to post the code?
>>
>>-Harish
>>
>>John Meredith wrote:
>>
>>
>>
>>>Cool. Just got this working, including caching it seems, although I'll
>>>need to do more tests just to make sure. I love working with Tapestry
>>>:-)
>>>
>>>If anyone's interested I'll post some more info.
>>>
>>> - John
>>>
>>>On Sun, 2003-08-03 at 14:01, John Meredith wrote:
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>As we've just been given the go-ahead to use Tapestry in our next
>>>>project, I've been thinking about dynamic template specification a
>>>>little more as we'll need to implement something for this to enable
>>>>syndication (with custom templates). Our requirement is not, however,
>>>>the ability to specify the template per component, but rather globally.
>>>>
>>>>I'd be inclined to implement the functionality in a manor analogous to
>>>>the way the Locale is handled at the moment (i.e. in the Engine). We'd
>>>>need a new property say TemplateClass (not related to CSS at all) which
>>>>could also be stored (as is the Locale) via a cookie client-side.
>>>>
>>>>The advantages I see in this approach (someone please correct me if I'm
>>>>wrong) is it would involve a relatively minimal change to the engine,
>>>>but would require some work in DefaultTemplateSource such that templates
>>>>are cached with along with their locale and their templateClass.
>>>>
>>>>The thing that one would need to agree on would be the template naming
>>>>conventions. I guess something like the way locale is handled presently
>>>>ie. pagename_en.html. I guess using something like
>>>>pagename_templategroupid_en.html would be possible, but it's not very
>>>>nice.
>>>>
>>>>Obviously, this would not allow you to specify a templateGroup per
>>>>component, but neither can you specify the locale of a component at
>>>>present (nor can I see a reason why you would want to).
>>>>
>>>>Can anyone see any problems with this approach? (I'm happy to be told
>>>>I'm a complete banana :-)
>>>>
>>>> John
>>>>
>>>>On Fri, 2003-08-01 at 19:41, Stefano Bagnara wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>>>What do you mean with "embeded component ids" ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>When templates are parsed components are identified and
>>>>>>matched with the
>>>>>>specification by their IDs. So if the template is going to
>>>>>>be decoupled
>>>>>>
>>>>>>
>>>>>>from the specification, there has to be a way of mapping the
>>>>>
>>>>>
>>>>>>component
>>>>>>in the template with that in the specification, right?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>This could be done in the page template or in the component
>>>>>specification:
>>>>>
>>>>><span jcwid="componentid@componentns:componenttype"
>>>>>jcwtemplate="differenttemplatename" />
>>>>>
>>>>>While you include a component you could declare a different template.
>>>>>The componentresolver is called everytime a similar line is found (i
>>>>>think) and if it loads 2 different components for
>>>>>"componentid@componentns:componenttype" and
>>>>>"componentid@componentns:componenttype" with jcwtemplate =
>>>>>"differenttemplatename" and the templateresolver use the
>>>>>"differenttemplatename" to find a different template at loadtime then it
>>>>>should work.
>>>>>
>>>>>Currently there is not templatepath specification: the resolver "assume"
>>>>>that the template is named like the component has an html extension
>>>>>(this is a parameter for tapestry) and it is in the same directory
>>>>>(maybe).
>>>>>
>>>>>Think at <span
>>>>>jcwid="componentid@componentns:componenttype|differenttemplatename" />
>>>>>if you want better compatibility with the current tapestry
>>>>>engine/resolvers.
>>>>>
>>>>>Please note I don't like the form
>>>>>componentid@componentns:componenttype|differenttemplatename but it is
>>>>>only an example.
>>>>>
>>>>>-b-
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>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
>>
>>