You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Amol Yadwadkar <ay...@webifyservices.com> on 2003/08/01 09:47:59 UTC
Needed Customised Images for Paging Mechanism for table Component
Hi MB,
I am using the Table Component
In that I will like to insert my own Images (Customise) for displaying the Paging Mechanism
<< < 1 2 3 > >> shall look like Page 1 of 2
What my Thinking/Understanding suggests me is I will have to replace images in JAR and Take a new Jar with Customised Images by replacing Images path in respective Java Beans designed by U for table Component.But this will be very Tedeious!!!!
Can U Pls. suggest me How shall I proceed further in acheiving the above.
Thankx
Best Regds,
Amol
Re: Needed Customised Images for Paging Mechanism for table Component
Posted by Amol Yadwadkar <ay...@webifyservices.com>.
Hey MB,
It worked very fine!!! I got my Images in place where I wanted.
Thankx a Lot!!!
Still there is a littlie Issue that Supposing I have to get the following then:-
A >> When I am the First Page then images for "Previous Page" and "First Page" shall be be DeActive
B >> Similarly vice-a-versa shall happen for the "Last Page" and "Next Page" Images when I am on the Last Page
Can U suggest me the Better way to get it Done?
Thankx Once again for the all extended Co-ordination!!!
Best Regds,
Amol
----- Original Message -----
From: Mind Bridge
To: Tapestry users ; Amol Yadwadkar
Sent: Friday, August 01, 2003 2:53 PM
Subject: RE: Needed Customised Images for Paging Mechanism for table Component
Hi Amol,
You would need to create your own implementation of the TablePages component that renders the appearance you want.
Take its files (TablePages.java, TablePages.jwc, TablePages.html) from the contrib source in package org.apache.tapestry.contrib.table.components and copy them to your application. Then feel free to modify the appearance of the copied component any way you like. Finally, define a component alias to it in the .application file and use that rather than contrib:TablePages in your application.
What you want to do is easy -- you will not even need to modify the original java file, since it provides all methods you need already. All you will need to do is make the template draw what you want.
Best regards,
-mb
P.S. I will not be available much today
-----Original Message-----
From: Amol Yadwadkar [mailto:ayadwadkar@webifyservices.com]
Sent: Friday, August 01, 2003 10:48 AM
To: Tapestry users
Subject: Needed Customised Images for Paging Mechanism for table Component
Hi MB,
I am using the Table Component
In that I will like to insert my own Images (Customise) for displaying the Paging Mechanism
<< < 1 2 3 > >> shall look like Page 1 of 2
What my Thinking/Understanding suggests me is I will have to replace images in JAR and Take a new Jar with Customised Images by replacing Images path in respective Java Beans designed by U for table Component.But this will be very Tedeious!!!!
Can U Pls. suggest me How shall I proceed further in acheiving the above.
Thankx
Best Regds,
Amol
RE: Needed Customised Images for Paging Mechanism for table
Component
Posted by John Meredith <ps...@t-online.de>.
Sorry .. I just found an explanation searching this list.
- John
On Sun, 2003-08-03 at 17:50, John Meredith wrote:
> Hi,
>
> I've started implementing my skinning idea below, and whilst going
> through the sources of Tapestry I found a couple of references to
> "$template" which seems to be an asset. Can anyone tell me what the
> "$template" asset is used for?
>
> - 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
--
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,
I've started implementing my skinning idea below, and whilst going
through the sources of Tapestry I found a couple of references to
"$template" which seems to be an asset. Can anyone tell me what the
"$template" asset is used for?
- 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
--
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
>>
>>
Re: Needed Customised Images for Paging Mechanism for
table Component
Posted by John Meredith <ps...@t-online.de>.
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 Harish Krishnaswamy <hk...@comcast.net>.
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
>>>
>>>
RE: Needed Customised Images for Paging Mechanism for table
Component
Posted by John Meredith <ps...@t-online.de>.
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
--
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,
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
--
John Meredith <ps...@t-online.de>
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Stefano Bagnara <ba...@ngi.it>.
> >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-
Re: Needed Customised Images for Paging Mechanism for table Component
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Stefano Bagnara wrote:
>>Yup, sorry, that's a little different than what I was thinking. Now I
>>get the picture. So are you saying that components will also have to
>>publish their embeded component ids in addition to their parameters?
>>
>>
>
>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?
>Is the ComponentID the "identifier@namespace:type" string ?
>
>
When I say component id, I mean the "indentifier" in
"identifier@namespace:type".
>I think you misunderstood my sample:
>
><span jcwid="@Calendar" jcwtemplate="/MyTemplates/MyCalendar.html" />
><span jcwid="@Calendar"
>jcwtemplate="ognl:visit.currentskin.calendartemplate" />
>
>In the second one I think that you have a method in your visit object
>(Visit.getCurrentSkin().getCalendarTemplate()) that return a string with
>the url to the calendar template for the current skin.
>
>I think the first can be done with little effort of code lines because
>you simply had to distinguish components with different templates at
>resolve time. (2 templates => 2 IComponents for the same jcw file).
>
>With the second (dynamic template) you have to recreate the component
>for every page request because visit.currentskin.calendartemplate could
>change and the components have already been resolved/loaded/cached.
>
>-b-
>
-Harish
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Stefano Bagnara <ba...@ngi.it>.
> Yup, sorry, that's a little different than what I was thinking. Now I
> get the picture. So are you saying that components will also have to
> publish their embeded component ids in addition to their parameters?
What do you mean with "embeded component ids" ?
Is the ComponentID the "identifier@namespace:type" string ?
I think you misunderstood my sample:
<span jcwid="@Calendar" jcwtemplate="/MyTemplates/MyCalendar.html" />
<span jcwid="@Calendar"
jcwtemplate="ognl:visit.currentskin.calendartemplate" />
In the second one I think that you have a method in your visit object
(Visit.getCurrentSkin().getCalendarTemplate()) that return a string with
the url to the calendar template for the current skin.
I think the first can be done with little effort of code lines because
you simply had to distinguish components with different templates at
resolve time. (2 templates => 2 IComponents for the same jcw file).
With the second (dynamic template) you have to recreate the component
for every page request because visit.currentskin.calendartemplate could
change and the components have already been resolved/loaded/cached.
-b-
Re: Needed Customised Images for Paging Mechanism for table Component
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Yup, sorry, that's a little different than what I was thinking. Now I
get the picture. So are you saying that components will also have to
publish their embeded component ids in addition to their parameters?
-Harish
Stefano Bagnara wrote:
>>I totally agree with you. I had the same question sometime
>>back (thread
>>http://article.gmane.org/gmane.comp.java.tapestry.user/2053)
>>and I was
>>trying to specify a variable template dynamically but like Howard
>>pointed out the issue was with cached pages which had its template
>>cached along with it. May be pages should be cached with a set of all
>>available skins. Would be interesting to see how that turns out
>>performance wise.
>>
>>
>
>Your question was a bit more advanced: my needs to change the html
>template for a given component are not dynamic!
>I simply said that the template property can be specified while
>including the component in the page specification or inside the page
>html
><span jcwid="@Calendar" jcwtemplate="/MyTemplates/MyCalendar.html" />
>Well... You would like an advanced view of this:
><span jcwid="@Calendar"
>jcwtemplate="ognl:visit.currentskin.calendartemplate" />
>I think that only this last one raise the caching problems.
>
>The Caching problem could be solved by caching components not only on a
>componentspecification base but using as a key both
>component-specification and the template. I've not looked at the
>involved sources but I'm sure tapestry is expandable enough to allow
>this change in few LOCs ;-) .
>
>-b-
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Stefano Bagnara <ba...@ngi.it>.
> I totally agree with you. I had the same question sometime
> back (thread
> http://article.gmane.org/gmane.comp.java.tapestry.user/2053)
> and I was
> trying to specify a variable template dynamically but like Howard
> pointed out the issue was with cached pages which had its template
> cached along with it. May be pages should be cached with a set of all
> available skins. Would be interesting to see how that turns out
> performance wise.
Your question was a bit more advanced: my needs to change the html
template for a given component are not dynamic!
I simply said that the template property can be specified while
including the component in the page specification or inside the page
html
<span jcwid="@Calendar" jcwtemplate="/MyTemplates/MyCalendar.html" />
Well... You would like an advanced view of this:
<span jcwid="@Calendar"
jcwtemplate="ognl:visit.currentskin.calendartemplate" />
I think that only this last one raise the caching problems.
The Caching problem could be solved by caching components not only on a
componentspecification base but using as a key both
component-specification and the template. I've not looked at the
involved sources but I'm sure tapestry is expandable enough to allow
this change in few LOCs ;-) .
-b-
Re: Needed Customised Images for Paging Mechanism for table Component
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I totally agree with you. I had the same question sometime back (thread
http://article.gmane.org/gmane.comp.java.tapestry.user/2053) and I was
trying to specify a variable template dynamically but like Howard
pointed out the issue was with cached pages which had its template
cached along with it. May be pages should be cached with a set of all
available skins. Would be interesting to see how that turns out
performance wise.
-Harish
Stefano Bagnara wrote:
>>One thing to keep in mind -- components are 'encapsulated'
>>and that ensures
>>that they can be used with the same interface (parameters)
>>even if their
>>implementation (template, spec, java bean) has been
>>completely changed.
>>Ideally, no one outside the component should 'know' specifics
>>about its
>>implementation except for what is provided by the interface, or the
>>encapsulation barrier brakes and the component is no longer really a
>>component (basically the whole OO idea goes to hell).
>>Defining templates
>>outside the components does precisely that. This limitation
>>may look silly
>>when working at a 'script' level, but when working on a 'web
>>application'
>>(rather than a 'web site') in a team, it is vital. Hence, the solution
>>Tapestry should offer must protect the encapsulation while offering
>>flexibility to change the appearance of the component. There
>>are a few ways
>>to achieve that. But that is another discussion.
>>
>>
>
>I understand component and encapsulation. But keep in mind that in OOP
>there is extension, implementation of interfaces, abstract classes and
>similar thing that allow simple extensibility of already existing
>"objects" (classes).
>
>Try to think to the comparison between a set of java objects extending
>the same abstract object and a set of htmltemplates for the same jwc
>component. You mantain the interface while extending an abstract class:
>in a similar way the properties of a component are declared in the jwc
>and what does it really show can be overridden by final implementations,
>by templates.
>
>I know this is a very different realm.. But I don't think that the
>ability to change the html template for a component would break the
>encapsulation as I see the component encapsulated in his template: you
>can have many templates encapsulating the same jcw as like as you can
>have many jcw using the same java classes. What would break the
>encapsulation is using the same template for different jwc, i think.
>
>Anyway... The template could be declared in the component specification.
>The new 3.0 way to declare some of the jcw information in the html
>template would allow the feature I'm asking for. We all know that the
>newly introduced style (in 3.0) is "less pure" than the old one... But
>you/we introduced it ;-) because someone can prefear it (giuda! :-P) !
>
>-b-
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Mind Bridge <mi...@yahoo.com>.
Hi Stefano,
Good points and I agree in general with what you say.
I am going away for a while shortly -- please continue the discussion with
Howard and the others (the -dev group would probably be best for that
purpose). Your thoughts about extending the framework would be of interest
to all of us, I believe.
Best regards,
-mb
-----Original Message-----
From: Stefano Bagnara [mailto:bago@ngi.it]
Sent: Friday, August 01, 2003 6:01 PM
To: 'Tapestry users'
Subject: RE: Needed Customised Images for Paging Mechanism for table
Component
> One thing to keep in mind -- components are 'encapsulated'
> and that ensures
> that they can be used with the same interface (parameters)
> even if their
> implementation (template, spec, java bean) has been
> completely changed.
> Ideally, no one outside the component should 'know' specifics
> about its
> implementation except for what is provided by the interface, or the
> encapsulation barrier brakes and the component is no longer really a
> component (basically the whole OO idea goes to hell).
> Defining templates
> outside the components does precisely that. This limitation
> may look silly
> when working at a 'script' level, but when working on a 'web
> application'
> (rather than a 'web site') in a team, it is vital. Hence, the solution
> Tapestry should offer must protect the encapsulation while offering
> flexibility to change the appearance of the component. There
> are a few ways
> to achieve that. But that is another discussion.
I understand component and encapsulation. But keep in mind that in OOP
there is extension, implementation of interfaces, abstract classes and
similar thing that allow simple extensibility of already existing
"objects" (classes).
Try to think to the comparison between a set of java objects extending
the same abstract object and a set of htmltemplates for the same jwc
component. You mantain the interface while extending an abstract class:
in a similar way the properties of a component are declared in the jwc
and what does it really show can be overridden by final implementations,
by templates.
I know this is a very different realm.. But I don't think that the
ability to change the html template for a component would break the
encapsulation as I see the component encapsulated in his template: you
can have many templates encapsulating the same jcw as like as you can
have many jcw using the same java classes. What would break the
encapsulation is using the same template for different jwc, i think.
Anyway... The template could be declared in the component specification.
The new 3.0 way to declare some of the jcw information in the html
template would allow the feature I'm asking for. We all know that the
newly introduced style (in 3.0) is "less pure" than the old one... But
you/we introduced it ;-) because someone can prefear it (giuda! :-P) !
-b-
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Stefano Bagnara <ba...@ngi.it>.
> One thing to keep in mind -- components are 'encapsulated'
> and that ensures
> that they can be used with the same interface (parameters)
> even if their
> implementation (template, spec, java bean) has been
> completely changed.
> Ideally, no one outside the component should 'know' specifics
> about its
> implementation except for what is provided by the interface, or the
> encapsulation barrier brakes and the component is no longer really a
> component (basically the whole OO idea goes to hell).
> Defining templates
> outside the components does precisely that. This limitation
> may look silly
> when working at a 'script' level, but when working on a 'web
> application'
> (rather than a 'web site') in a team, it is vital. Hence, the solution
> Tapestry should offer must protect the encapsulation while offering
> flexibility to change the appearance of the component. There
> are a few ways
> to achieve that. But that is another discussion.
I understand component and encapsulation. But keep in mind that in OOP
there is extension, implementation of interfaces, abstract classes and
similar thing that allow simple extensibility of already existing
"objects" (classes).
Try to think to the comparison between a set of java objects extending
the same abstract object and a set of htmltemplates for the same jwc
component. You mantain the interface while extending an abstract class:
in a similar way the properties of a component are declared in the jwc
and what does it really show can be overridden by final implementations,
by templates.
I know this is a very different realm.. But I don't think that the
ability to change the html template for a component would break the
encapsulation as I see the component encapsulated in his template: you
can have many templates encapsulating the same jcw as like as you can
have many jcw using the same java classes. What would break the
encapsulation is using the same template for different jwc, i think.
Anyway... The template could be declared in the component specification.
The new 3.0 way to declare some of the jcw information in the html
template would allow the feature I'm asking for. We all know that the
newly introduced style (in 3.0) is "less pure" than the old one... But
you/we introduced it ;-) because someone can prefear it (giuda! :-P) !
-b-
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Mind Bridge <mi...@yahoo.com>.
Hi Stefano,
> Is there a way to say tapestry I want to use a "standard" component but
> with a custom html template provided by me without having to create a
> new component specification too?
No, I am afraid this is not currently possible. It is possible to reuse the
Java bean by making a new component but specifying the same class in the
component descriptor. That is not exactly what you describe though.
Nevertheless, there have been a lot of similar requests lately for
'skinning' and related functionality, so my guess is that solutions would be
discussed soon.
One thing to keep in mind -- components are 'encapsulated' and that ensures
that they can be used with the same interface (parameters) even if their
implementation (template, spec, java bean) has been completely changed.
Ideally, no one outside the component should 'know' specifics about its
implementation except for what is provided by the interface, or the
encapsulation barrier brakes and the component is no longer really a
component (basically the whole OO idea goes to hell). Defining templates
outside the components does precisely that. This limitation may look silly
when working at a 'script' level, but when working on a 'web application'
(rather than a 'web site') in a team, it is vital. Hence, the solution
Tapestry should offer must protect the encapsulation while offering
flexibility to change the appearance of the component. There are a few ways
to achieve that. But that is another discussion.
Best regards,
-mb
-----Original Message-----
From: Stefano Bagnara [mailto:bago@ngi.it]
Sent: Friday, August 01, 2003 1:08 PM
To: 'Tapestry users'
Subject: RE: Needed Customised Images for Paging Mechanism for table
Component
> What you want to do is easy -- you will not even need to
> modify the original
> java file, since it provides all methods you need already.
> All you will need
> to do is make the template draw what you want.
Is there a way to say tapestry I want to use a "standard" component but
with a custom html template provided by me without having to create a
new component specification too?
I'm very new to tapestry and I don't know if this can be done already:
what about allowing an user to specify a new html template as a
component parameter?
<span jcwid="@Border" jcwtemplate="MyCustomBorder.html">content</span>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Stefano Bagnara <ba...@ngi.it>.
> What you want to do is easy -- you will not even need to
> modify the original
> java file, since it provides all methods you need already.
> All you will need
> to do is make the template draw what you want.
Is there a way to say tapestry I want to use a "standard" component but
with a custom html template provided by me without having to create a
new component specification too?
I'm very new to tapestry and I don't know if this can be done already:
what about allowing an user to specify a new html template as a
component parameter?
<span jcwid="@Border" jcwtemplate="MyCustomBorder.html">content</span>
RE: Needed Customised Images for Paging Mechanism for table Component
Posted by Mind Bridge <mi...@yahoo.com>.
Hi Amol,
You would need to create your own implementation of the TablePages component
that renders the appearance you want.
Take its files (TablePages.java, TablePages.jwc, TablePages.html) from the
contrib source in package org.apache.tapestry.contrib.table.components and
copy them to your application. Then feel free to modify the appearance of
the copied component any way you like. Finally, define a component alias to
it in the .application file and use that rather than contrib:TablePages in
your application.
What you want to do is easy -- you will not even need to modify the original
java file, since it provides all methods you need already. All you will need
to do is make the template draw what you want.
Best regards,
-mb
P.S. I will not be available much today
-----Original Message-----
From: Amol Yadwadkar [mailto:ayadwadkar@webifyservices.com]
Sent: Friday, August 01, 2003 10:48 AM
To: Tapestry users
Subject: Needed Customised Images for Paging Mechanism for table Component
Hi MB,
I am using the Table Component
In that I will like to insert my own Images (Customise) for displaying the
Paging Mechanism
<< < 1 2 3 > >> shall look like Page 1 of 2
What my Thinking/Understanding suggests me is I will have to replace
images in JAR and Take a new Jar with Customised Images by replacing Images
path in respective Java Beans designed by U for table Component.But this
will be very Tedeious!!!!
Can U Pls. suggest me How shall I proceed further in acheiving the above.
Thankx
Best Regds,
Amol