Re: No context for a t:select?
Worked perfectly. Thanks -- View this message in context: http://tapestry.1045711.n5.nabble.com/No-context-for-a-t-select-tp3398655p4556553.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
Here's mine:
@Log
void onChange(String primary, String secondary, String categoryName)
{
And what it does:
2011-07-05 16:52:07,899 [qtp1317701801-91] DEBUG -[ENTER]
onChange("e1718719-df6e-4bc4-a25d-4b7c83b0baae",
"7486318b-3f15-4735-be78-0d42ec778e1b", "category1")
--
View this message in context:
http://tapestry-users.832.n2.nabble.com/No-context-for-a-t-select-tp6060602p6551701.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
Hi lltyk, thanks for the reply.
I'm using your suggestion as followed and it only passes back the select
menu option id and ignors my context parameters. Any suggestions? Thanks.
Object onNewFundingChanged() {
String newFunding = request.getParameter("param");
System.out.println(newFunding);
return fundingZone.getBody();
}
return null;
}
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/No-context-for-a-t-select-tp3398655p4554600.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
I have something like that floating in my code. Doesn't have to be selectobject and could be a plain select, but you need zoneupdater. -- View this message in context: http://tapestry-users.832.n2.nabble.com/No-context-for-a-t-select-tp6060602p6551150.html Sent from the Tapestry Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
Hi Richard, do you know if there has been any progress made on this feature? -- View this message in context: http://tapestry.1045711.n5.nabble.com/No-context-for-a-t-select-tp3398655p4553978.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
Hi Thiago. Do you know if this issue has been resolved? I have multiple select menus in a grid using onValueChanged that all control a single ajax popup form. I need to pass the row id into the form. Thanks in advance! -- View this message in context: http://tapestry.1045711.n5.nabble.com/No-context-for-a-t-select-tp3398655p4529395.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
;) ya sorry, I meant implementation ! On Feb 26, 2011 7:12 AM, "Thiago H. de Paula Figueiredo" wrote: > On Sat, 26 Feb 2011 10:12:40 -0300, Andreas Andreou > wrote: > >> On Fri, Feb 25, 2011 at 20:23, Josh Canfield >> wrote: They wouldn't see the difference - they'd be using the component that would internally use the mixin >>> >>> Actually, I wasn't thinking of an internal mixin. Putting a "zone" on >>> the Select seems random, making it an internal mixin doesn't make it >>> any less random. >> >> What is an internal mixin? It needs to be a normal, public mixin for >> users to use anywhere (most likely it should be a copy of zoneupdater). > > I think ZoneUpdater or something similar should be added to Tapestry.js. > Its usage is common enough and the code addition would be small enough. > >> And it needs to be attached to Select by default due to backwards >> compatibility - if that's not a requirement, then i fully agree with you. > > I guess Josh said internal mixin meaning implementation mixin (i.e > declared inside the component). > Either way, I think the Select update zone code should be extracted to a > mixin (ZoneUpdater?) which would be added to Select as an implementation > one for backward compatibility. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
Re: No context for a t:select?
On Sat, 26 Feb 2011 10:12:40 -0300, Andreas Andreou wrote: On Fri, Feb 25, 2011 at 20:23, Josh Canfield wrote: They wouldn't see the difference - they'd be using the component that would internally use the mixin Actually, I wasn't thinking of an internal mixin. Putting a "zone" on the Select seems random, making it an internal mixin doesn't make it any less random. What is an internal mixin? It needs to be a normal, public mixin for users to use anywhere (most likely it should be a copy of zoneupdater). I think ZoneUpdater or something similar should be added to Tapestry.js. Its usage is common enough and the code addition would be small enough. And it needs to be attached to Select by default due to backwards compatibility - if that's not a requirement, then i fully agree with you. I guess Josh said internal mixin meaning implementation mixin (i.e declared inside the component). Either way, I think the Select update zone code should be extracted to a mixin (ZoneUpdater?) which would be added to Select as an implementation one for backward compatibility. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
On Fri, Feb 25, 2011 at 20:23, Josh Canfield wrote: >> They wouldn't see the difference - they'd be using the component that >> would internally >> use the mixin > > Actually, I wasn't thinking of an internal mixin. Putting a "zone" on > the Select seems random, making it an internal mixin doesn't make it > any less random. What is an internal mixin? It needs to be a normal, public mixin for users to use anywhere (most likely it should be a copy of zoneupdater). And it needs to be attached to Select by default due to backwards compatibility - if that's not a requirement, then i fully agree with you. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
> I'm not sure I follow this. It's useful for the list/loop scenario I
> described where you need to get back both the new option value and the
> context (e.g object id) to which the change refers. Whether the response
> is a full or partial page is not relevant, I think.
I don't see it. Without the "zone" parameter you actually post the
form, and if you need loop context it's stored in a hidden field in
the form (depending on your form state parameter)
A full page render implies a post of the form, and if you need a
context for select then this would imply that you need a context for
every form element to handle a form submit.
> mixins is another
> subject that a newbie/new adopter has to learn, whereas they are already
> familiar with context and zone parameters from fundamental components
> like an actionlink.
:) They will be better for it. Putting a zone on a Select isn't the
same as putting it on an event link. With a link you are extending
it's existing behavior; instead of rendering a new page, render in
this portal. With a Select adding a Zone has nothing to do with it's
original purpose of letting you choose a value to be sent back to the
server.
Josh
On Fri, Feb 25, 2011 at 4:16 AM, Richard Hill wrote:
> On Thu, 2011-02-24 at 11:12 -0800, Josh Canfield wrote:
>> > Yes agreed - I think t:select should take an optional context parameter.
>>
>> I guess it's a little late to second guess the wisdom of adding a
>> "zone" parameter to the Select component in the first place... I
>> hadn't noticed it until now. This functionality could have been
>> provided as a mixin and then applied to Radio and Checkbox as well...
>
> I think a zone parameter for a Select is pretty useful. Yes maybe you
> can concoct a mixin with the same functionality but this is more
> development overhead.
>
>> A context parameter doesn't make sense outside of the ajax update
>> scenario. Someone will inevitably try to use the attribute outside of
>> an ajax update and file another defect.
>
> I'm not sure I follow this. It's useful for the list/loop scenario I
> described where you need to get back both the new option value and the
> context (e.g object id) to which the change refers. Whether the response
> is a full or partial page is not relevant, I think.
>
>> Would it be reasonable to instead provide an OnChange mixin in core
>> (one exists in a third party library already, right?) that handled the
>> context correctly?
>
> If a core mixin was provided that may fill this gap, and ditto for radio
> or checkboxes. But - and this is just my 2 pence - mixins is another
> subject that a newbie/new adopter has to learn, whereas they are already
> familiar with context and zone parameters from fundamental components
> like an actionlink.
>
>
>>
>> Josh
>>
>> On Thu, Feb 24, 2011 at 8:49 AM, Richard Hill wrote:
>> >
>> > Yes agreed - I think t:select should take an optional context parameter.
>> > I will file a JIRA.
>> >
>> > As a work around I see two options:
>> >
>> > 1) In my case here I don't need to actually re-render a zone when the
>> > user changes the selection. So I will probably just render the select
>> > "manually" and attach my own js handler to fire back the change to the
>> > server.
>> >
>> > 2) If you did require a zone update, I think you would have to use
>> > context-dependent select and option models which provided client-side
>> > option values that were some combination of the context and option id.
>> > These could then be parsed out server-side when a user makes his
>> > selection. But sounds a bit hacky :)
>> >
>> > Thiago - thanks for your help and patience on this.
>> >
>> > Cheers Richard
>> >
>> >
>> >
>> >
>> >
>> > On Thu, 2011-02-24 at 13:24 -0300, Thiago H. de Paula Figueiredo wrote:
>> >> On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
>> >> wrote:
>> >>
>> >> > Thanks for this. I think I understand better what ValueEncoder does now.
>> >> > However, this doesn't answer my question: when I say "context" I mean
>> >> > the loop context - not the option value that was selected. This I know
>> >> > how to get, but I don't know for which loop item it refers.
>> >>
>> >> The Loop component doesn't have a context, so now I know what you were
>> >> talking about.
>> >>
>> >> > Let's say I have a list of pens, and each can be red, blue or green:
>> >> >
>> >> >
>> >> > ${pen.id}
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > The penModel just models the three possible colors, penOption is the
>> >> > selected color.
>> >> >
>> >> > Now when a user makes a change, the onValueChangedFromPenSelect(Color
>> >> > color) method is called.
>> >> >
>> >> > No problem - but for which pen is it called? Without a loop context I do
>> >> > not know this.
>> >>
>> >> The example makes it all very clear. It seems to me that Select needs an
>> >> improvement: having a context parameter that allows you to pass more
>> >> values to the event handler method. For example, your method would be
>> >> onValueC
Re: No context for a t:select?
> They wouldn't see the difference - they'd be using the component that
> would internally
> use the mixin
Actually, I wasn't thinking of an internal mixin. Putting a "zone" on
the Select seems random, making it an internal mixin doesn't make it
any less random.
I would prefer that this functionality be treated the same way as
Autocomplete on a Textfield. The ZoneUpdater is a great example of
providing a flexible way to add functionality without hanging more
features of individual components.
Josh
On Fri, Feb 25, 2011 at 4:58 AM, Andreas Andreou wrote:
>> If a core mixin was provided that may fill this gap, and ditto for radio
>> or checkboxes. But - and this is just my 2 pence - mixins is another
>> subject that a newbie/new adopter has to learn, whereas they are already
>> familiar with context and zone parameters from fundamental components
>> like an actionlink.
>
> They wouldn't see the difference - they'd be using the component that
> would internally
> use the mixin. They won't need to specify the mixin themselves.
> Take a look at http://tapestry.apache.org/component-mixins.html in the section
> "Implementation Mixins" for how this can work and why it's not *yet*
> possible to build this!
>
>
>>>
>>> Josh
>>>
>>> On Thu, Feb 24, 2011 at 8:49 AM, Richard Hill wrote:
>>> >
>>> > Yes agreed - I think t:select should take an optional context parameter.
>>> > I will file a JIRA.
>>> >
>>> > As a work around I see two options:
>>> >
>>> > 1) In my case here I don't need to actually re-render a zone when the
>>> > user changes the selection. So I will probably just render the select
>>> > "manually" and attach my own js handler to fire back the change to the
>>> > server.
>>> >
>>> > 2) If you did require a zone update, I think you would have to use
>>> > context-dependent select and option models which provided client-side
>>> > option values that were some combination of the context and option id.
>>> > These could then be parsed out server-side when a user makes his
>>> > selection. But sounds a bit hacky :)
>>> >
>>> > Thiago - thanks for your help and patience on this.
>>> >
>>> > Cheers Richard
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, 2011-02-24 at 13:24 -0300, Thiago H. de Paula Figueiredo wrote:
>>> >> On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
>>> >> wrote:
>>> >>
>>> >> > Thanks for this. I think I understand better what ValueEncoder does
>>> >> > now.
>>> >> > However, this doesn't answer my question: when I say "context" I mean
>>> >> > the loop context - not the option value that was selected. This I know
>>> >> > how to get, but I don't know for which loop item it refers.
>>> >>
>>> >> The Loop component doesn't have a context, so now I know what you were
>>> >> talking about.
>>> >>
>>> >> > Let's say I have a list of pens, and each can be red, blue or green:
>>> >> >
>>> >> >
>>> >> > ${pen.id}
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > The penModel just models the three possible colors, penOption is the
>>> >> > selected color.
>>> >> >
>>> >> > Now when a user makes a change, the onValueChangedFromPenSelect(Color
>>> >> > color) method is called.
>>> >> >
>>> >> > No problem - but for which pen is it called? Without a loop context I
>>> >> > do
>>> >> > not know this.
>>> >>
>>> >> The example makes it all very clear. It seems to me that Select needs an
>>> >> improvement: having a context parameter that allows you to pass more
>>> >> values to the event handler method. For example, your method would be
>>> >> onValueChangedFromPenSelect(Color color, XXX xxx). Please file a JIRA
>>> >> about it.
>>> >>
>>> >> > Given what you've said about value encoder, can I use this to store
>>> >> > some
>>> >> > combination of both the pen id and the color id as the option value?
>>> >>
>>> >> I think that's technically possible, but I'd not recommend that.
>>> >>
>>> >
>>> >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> > For additional commands, e-mail: users-h...@tapestry.apache.org
>>> >
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
>
>
> --
> Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr
> Apache Tapestry PMC / http://chesstu.be owner
> Open Source / JEE Consulting
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
-
To unsubsc
Re: No context for a t:select?
> If a core mixin was provided that may fill this gap, and ditto for radio
> or checkboxes. But - and this is just my 2 pence - mixins is another
> subject that a newbie/new adopter has to learn, whereas they are already
> familiar with context and zone parameters from fundamental components
> like an actionlink.
They wouldn't see the difference - they'd be using the component that
would internally
use the mixin. They won't need to specify the mixin themselves.
Take a look at http://tapestry.apache.org/component-mixins.html in the section
"Implementation Mixins" for how this can work and why it's not *yet*
possible to build this!
>>
>> Josh
>>
>> On Thu, Feb 24, 2011 at 8:49 AM, Richard Hill wrote:
>> >
>> > Yes agreed - I think t:select should take an optional context parameter.
>> > I will file a JIRA.
>> >
>> > As a work around I see two options:
>> >
>> > 1) In my case here I don't need to actually re-render a zone when the
>> > user changes the selection. So I will probably just render the select
>> > "manually" and attach my own js handler to fire back the change to the
>> > server.
>> >
>> > 2) If you did require a zone update, I think you would have to use
>> > context-dependent select and option models which provided client-side
>> > option values that were some combination of the context and option id.
>> > These could then be parsed out server-side when a user makes his
>> > selection. But sounds a bit hacky :)
>> >
>> > Thiago - thanks for your help and patience on this.
>> >
>> > Cheers Richard
>> >
>> >
>> >
>> >
>> >
>> > On Thu, 2011-02-24 at 13:24 -0300, Thiago H. de Paula Figueiredo wrote:
>> >> On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
>> >> wrote:
>> >>
>> >> > Thanks for this. I think I understand better what ValueEncoder does now.
>> >> > However, this doesn't answer my question: when I say "context" I mean
>> >> > the loop context - not the option value that was selected. This I know
>> >> > how to get, but I don't know for which loop item it refers.
>> >>
>> >> The Loop component doesn't have a context, so now I know what you were
>> >> talking about.
>> >>
>> >> > Let's say I have a list of pens, and each can be red, blue or green:
>> >> >
>> >> >
>> >> > ${pen.id}
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > The penModel just models the three possible colors, penOption is the
>> >> > selected color.
>> >> >
>> >> > Now when a user makes a change, the onValueChangedFromPenSelect(Color
>> >> > color) method is called.
>> >> >
>> >> > No problem - but for which pen is it called? Without a loop context I do
>> >> > not know this.
>> >>
>> >> The example makes it all very clear. It seems to me that Select needs an
>> >> improvement: having a context parameter that allows you to pass more
>> >> values to the event handler method. For example, your method would be
>> >> onValueChangedFromPenSelect(Color color, XXX xxx). Please file a JIRA
>> >> about it.
>> >>
>> >> > Given what you've said about value encoder, can I use this to store some
>> >> > combination of both the pen id and the color id as the option value?
>> >>
>> >> I think that's technically possible, but I'd not recommend that.
>> >>
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> > For additional commands, e-mail: users-h...@tapestry.apache.org
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr
Apache Tapestry PMC / http://chesstu.be owner
Open Source / JEE Consulting
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
On Thu, 2011-02-24 at 11:12 -0800, Josh Canfield wrote:
> > Yes agreed - I think t:select should take an optional context parameter.
>
> I guess it's a little late to second guess the wisdom of adding a
> "zone" parameter to the Select component in the first place... I
> hadn't noticed it until now. This functionality could have been
> provided as a mixin and then applied to Radio and Checkbox as well...
I think a zone parameter for a Select is pretty useful. Yes maybe you
can concoct a mixin with the same functionality but this is more
development overhead.
> A context parameter doesn't make sense outside of the ajax update
> scenario. Someone will inevitably try to use the attribute outside of
> an ajax update and file another defect.
I'm not sure I follow this. It's useful for the list/loop scenario I
described where you need to get back both the new option value and the
context (e.g object id) to which the change refers. Whether the response
is a full or partial page is not relevant, I think.
> Would it be reasonable to instead provide an OnChange mixin in core
> (one exists in a third party library already, right?) that handled the
> context correctly?
If a core mixin was provided that may fill this gap, and ditto for radio
or checkboxes. But - and this is just my 2 pence - mixins is another
subject that a newbie/new adopter has to learn, whereas they are already
familiar with context and zone parameters from fundamental components
like an actionlink.
>
> Josh
>
> On Thu, Feb 24, 2011 at 8:49 AM, Richard Hill wrote:
> >
> > Yes agreed - I think t:select should take an optional context parameter.
> > I will file a JIRA.
> >
> > As a work around I see two options:
> >
> > 1) In my case here I don't need to actually re-render a zone when the
> > user changes the selection. So I will probably just render the select
> > "manually" and attach my own js handler to fire back the change to the
> > server.
> >
> > 2) If you did require a zone update, I think you would have to use
> > context-dependent select and option models which provided client-side
> > option values that were some combination of the context and option id.
> > These could then be parsed out server-side when a user makes his
> > selection. But sounds a bit hacky :)
> >
> > Thiago - thanks for your help and patience on this.
> >
> > Cheers Richard
> >
> >
> >
> >
> >
> > On Thu, 2011-02-24 at 13:24 -0300, Thiago H. de Paula Figueiredo wrote:
> >> On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
> >> wrote:
> >>
> >> > Thanks for this. I think I understand better what ValueEncoder does now.
> >> > However, this doesn't answer my question: when I say "context" I mean
> >> > the loop context - not the option value that was selected. This I know
> >> > how to get, but I don't know for which loop item it refers.
> >>
> >> The Loop component doesn't have a context, so now I know what you were
> >> talking about.
> >>
> >> > Let's say I have a list of pens, and each can be red, blue or green:
> >> >
> >> >
> >> > ${pen.id}
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > The penModel just models the three possible colors, penOption is the
> >> > selected color.
> >> >
> >> > Now when a user makes a change, the onValueChangedFromPenSelect(Color
> >> > color) method is called.
> >> >
> >> > No problem - but for which pen is it called? Without a loop context I do
> >> > not know this.
> >>
> >> The example makes it all very clear. It seems to me that Select needs an
> >> improvement: having a context parameter that allows you to pass more
> >> values to the event handler method. For example, your method would be
> >> onValueChangedFromPenSelect(Color color, XXX xxx). Please file a JIRA
> >> about it.
> >>
> >> > Given what you've said about value encoder, can I use this to store some
> >> > combination of both the pen id and the color id as the option value?
> >>
> >> I think that's technically possible, but I'd not recommend that.
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
On Thu, 24 Feb 2011 18:19:39 -0300, Andreas Andreou wrote: That's exactly why i asked the question about implementation mixins in the dev list ( http://markmail.org/thread/ft755d4vbkfaip4v ) Cool! And there's no reason to restict it to onchange events - anyway, i'll open some related jira issues tonight... Agreed. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
That's exactly why i asked the question about implementation
mixins in the dev list ( http://markmail.org/thread/ft755d4vbkfaip4v )
And there's no reason to restict it to onchange events - anyway, i'll
open some related jira issues tonight...
On Thu, Feb 24, 2011 at 21:12, Josh Canfield wrote:
>> Yes agreed - I think t:select should take an optional context parameter.
>
> I guess it's a little late to second guess the wisdom of adding a
> "zone" parameter to the Select component in the first place... I
> hadn't noticed it until now. This functionality could have been
> provided as a mixin and then applied to Radio and Checkbox as well...
>
> A context parameter doesn't make sense outside of the ajax update
> scenario. Someone will inevitably try to use the attribute outside of
> an ajax update and file another defect.
>
> Would it be reasonable to instead provide an OnChange mixin in core
> (one exists in a third party library already, right?) that handled the
> context correctly?
>
> Josh
>
> On Thu, Feb 24, 2011 at 8:49 AM, Richard Hill wrote:
>>
>> Yes agreed - I think t:select should take an optional context parameter.
>> I will file a JIRA.
>>
>> As a work around I see two options:
>>
>> 1) In my case here I don't need to actually re-render a zone when the
>> user changes the selection. So I will probably just render the select
>> "manually" and attach my own js handler to fire back the change to the
>> server.
>>
>> 2) If you did require a zone update, I think you would have to use
>> context-dependent select and option models which provided client-side
>> option values that were some combination of the context and option id.
>> These could then be parsed out server-side when a user makes his
>> selection. But sounds a bit hacky :)
>>
>> Thiago - thanks for your help and patience on this.
>>
>> Cheers Richard
>>
>>
>>
>>
>>
>> On Thu, 2011-02-24 at 13:24 -0300, Thiago H. de Paula Figueiredo wrote:
>>> On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
>>> wrote:
>>>
>>> > Thanks for this. I think I understand better what ValueEncoder does now.
>>> > However, this doesn't answer my question: when I say "context" I mean
>>> > the loop context - not the option value that was selected. This I know
>>> > how to get, but I don't know for which loop item it refers.
>>>
>>> The Loop component doesn't have a context, so now I know what you were
>>> talking about.
>>>
>>> > Let's say I have a list of pens, and each can be red, blue or green:
>>> >
>>> >
>>> > ${pen.id}
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > The penModel just models the three possible colors, penOption is the
>>> > selected color.
>>> >
>>> > Now when a user makes a change, the onValueChangedFromPenSelect(Color
>>> > color) method is called.
>>> >
>>> > No problem - but for which pen is it called? Without a loop context I do
>>> > not know this.
>>>
>>> The example makes it all very clear. It seems to me that Select needs an
>>> improvement: having a context parameter that allows you to pass more
>>> values to the event handler method. For example, your method would be
>>> onValueChangedFromPenSelect(Color color, XXX xxx). Please file a JIRA
>>> about it.
>>>
>>> > Given what you've said about value encoder, can I use this to store some
>>> > combination of both the pen id and the color id as the option value?
>>>
>>> I think that's technically possible, but I'd not recommend that.
>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr
Apache Tapestry PMC / http://chesstu.be owner
Open Source / JEE Consulting
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
On Thu, 24 Feb 2011 16:12:10 -0300, Josh Canfield wrote: Yes agreed - I think t:select should take an optional context parameter. I guess it's a little late to second guess the wisdom of adding a "zone" parameter to the Select component in the first place... I hadn't noticed it until now. This functionality could have been provided as a mixin and then applied to Radio and Checkbox as well... We can still write this plugin and leave Select as is. A context parameter doesn't make sense outside of the ajax update scenario. Someone will inevitably try to use the attribute outside of an ajax update and file another defect. What about ajaxContext instead of context in this case? Would it be reasonable to instead provide an OnChange mixin in core (one exists in a third party library already, right?) that handled the context correctly? I think so. Tapestry 4 was quite easy to make AJAX updates in response to arbitrary JavaScript events. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
> Yes agreed - I think t:select should take an optional context parameter.
I guess it's a little late to second guess the wisdom of adding a
"zone" parameter to the Select component in the first place... I
hadn't noticed it until now. This functionality could have been
provided as a mixin and then applied to Radio and Checkbox as well...
A context parameter doesn't make sense outside of the ajax update
scenario. Someone will inevitably try to use the attribute outside of
an ajax update and file another defect.
Would it be reasonable to instead provide an OnChange mixin in core
(one exists in a third party library already, right?) that handled the
context correctly?
Josh
On Thu, Feb 24, 2011 at 8:49 AM, Richard Hill wrote:
>
> Yes agreed - I think t:select should take an optional context parameter.
> I will file a JIRA.
>
> As a work around I see two options:
>
> 1) In my case here I don't need to actually re-render a zone when the
> user changes the selection. So I will probably just render the select
> "manually" and attach my own js handler to fire back the change to the
> server.
>
> 2) If you did require a zone update, I think you would have to use
> context-dependent select and option models which provided client-side
> option values that were some combination of the context and option id.
> These could then be parsed out server-side when a user makes his
> selection. But sounds a bit hacky :)
>
> Thiago - thanks for your help and patience on this.
>
> Cheers Richard
>
>
>
>
>
> On Thu, 2011-02-24 at 13:24 -0300, Thiago H. de Paula Figueiredo wrote:
>> On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
>> wrote:
>>
>> > Thanks for this. I think I understand better what ValueEncoder does now.
>> > However, this doesn't answer my question: when I say "context" I mean
>> > the loop context - not the option value that was selected. This I know
>> > how to get, but I don't know for which loop item it refers.
>>
>> The Loop component doesn't have a context, so now I know what you were
>> talking about.
>>
>> > Let's say I have a list of pens, and each can be red, blue or green:
>> >
>> >
>> > ${pen.id}
>> >
>> >
>> >
>> >
>> >
>> > The penModel just models the three possible colors, penOption is the
>> > selected color.
>> >
>> > Now when a user makes a change, the onValueChangedFromPenSelect(Color
>> > color) method is called.
>> >
>> > No problem - but for which pen is it called? Without a loop context I do
>> > not know this.
>>
>> The example makes it all very clear. It seems to me that Select needs an
>> improvement: having a context parameter that allows you to pass more
>> values to the event handler method. For example, your method would be
>> onValueChangedFromPenSelect(Color color, XXX xxx). Please file a JIRA
>> about it.
>>
>> > Given what you've said about value encoder, can I use this to store some
>> > combination of both the pen id and the color id as the option value?
>>
>> I think that's technically possible, but I'd not recommend that.
>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
Yes agreed - I think t:select should take an optional context parameter.
I will file a JIRA.
As a work around I see two options:
1) In my case here I don't need to actually re-render a zone when the
user changes the selection. So I will probably just render the select
"manually" and attach my own js handler to fire back the change to the
server.
2) If you did require a zone update, I think you would have to use
context-dependent select and option models which provided client-side
option values that were some combination of the context and option id.
These could then be parsed out server-side when a user makes his
selection. But sounds a bit hacky :)
Thiago - thanks for your help and patience on this.
Cheers Richard
On Thu, 2011-02-24 at 13:24 -0300, Thiago H. de Paula Figueiredo wrote:
> On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
> wrote:
>
> > Thanks for this. I think I understand better what ValueEncoder does now.
> > However, this doesn't answer my question: when I say "context" I mean
> > the loop context - not the option value that was selected. This I know
> > how to get, but I don't know for which loop item it refers.
>
> The Loop component doesn't have a context, so now I know what you were
> talking about.
>
> > Let's say I have a list of pens, and each can be red, blue or green:
> >
> >
> > ${pen.id}
> >
> >
> >
> >
> >
> > The penModel just models the three possible colors, penOption is the
> > selected color.
> >
> > Now when a user makes a change, the onValueChangedFromPenSelect(Color
> > color) method is called.
> >
> > No problem - but for which pen is it called? Without a loop context I do
> > not know this.
>
> The example makes it all very clear. It seems to me that Select needs an
> improvement: having a context parameter that allows you to pass more
> values to the event handler method. For example, your method would be
> onValueChangedFromPenSelect(Color color, XXX xxx). Please file a JIRA
> about it.
>
> > Given what you've said about value encoder, can I use this to store some
> > combination of both the pen id and the color id as the option value?
>
> I think that's technically possible, but I'd not recommend that.
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
On Thu, 24 Feb 2011 13:15:51 -0300, Richard Hill
wrote:
Thanks for this. I think I understand better what ValueEncoder does now.
However, this doesn't answer my question: when I say "context" I mean
the loop context - not the option value that was selected. This I know
how to get, but I don't know for which loop item it refers.
The Loop component doesn't have a context, so now I know what you were
talking about.
Let's say I have a list of pens, and each can be red, blue or green:
${pen.id}
The penModel just models the three possible colors, penOption is the
selected color.
Now when a user makes a change, the onValueChangedFromPenSelect(Color
color) method is called.
No problem - but for which pen is it called? Without a loop context I do
not know this.
The example makes it all very clear. It seems to me that Select needs an
improvement: having a context parameter that allows you to pass more
values to the event handler method. For example, your method would be
onValueChangedFromPenSelect(Color color, XXX xxx). Please file a JIRA
about it.
Given what you've said about value encoder, can I use this to store some
combination of both the pen id and the color id as the option value?
I think that's technically possible, but I'd not recommend that.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
Thanks for this. I think I understand better what ValueEncoder does now.
However, this doesn't answer my question: when I say "context" I mean
the loop context - not the option value that was selected. This I know
how to get, but I don't know for which loop item it refers.
Let's say I have a list of pens, and each can be red, blue or green:
${pen.id}
The penModel just models the three possible colors, penOption is the
selected color.
Now when a user makes a change, the onValueChangedFromPenSelect(Color
color) method is called.
No problem - but for which pen is it called? Without a loop context I do
not know this.
Given what you've said about value encoder, can I use this to store some
combination of both the pen id and the color id as the option value?
On Thu, 2011-02-24 at 12:34 -0300, Thiago H. de Paula Figueiredo wrote:
> On Thu, 24 Feb 2011 11:58:26 -0300, Richard Hill
> wrote:
>
> > Hi - again :)
>
> Hi!
>
> > I am supplying select and option models, which seem to work fine. But
> > how how do I supply a context? The t:select component does not appear to
> > take one. Without this I cannot know to what object my state change
> > relates.
>
> Have you read the Select component documentation?
> (http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Select.html).
> "The event handler method for the event valuechanged is used to provide
> the available car models of the currently selected car maker. The new
> Select's value is passed as context."
>
> public Object onValueChanged(CarMaker maker)
>
> In other words: you will receive the selected option as the event handler
> method parameter.
>
> > I've looked at valueencoders, but according to the docs, and from what
> > Thiago said yesterday, this seems to be alternative approach to using
> > models, which doesn't help.
>
> I haven't said that. ValueEncoder and SelectModel are not alternative
> approaches to do the same thing. They do different things: SelectModel
> provides the options (including labels) and ValueEncoder encodes them for
> the value attribute of the option tag.
>
> Here's the description from the SelectModel javadoc:
>
> "(SelectModel) Defines the possible options and option groups for a
> [X]HTML element.
>
> Primarily used by the Select component, but potentially used by anything
> similar, that needs to present a list of options to the user. Generally
> paired with a ValueEncoder to create client-side representations of
> server-side values."
>
> Please read the documentation before asking. ;)
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: No context for a t:select?
Hi Thiago,
Thanks for this. I think I understand better what ValueEncoder does now.
However, this doesn't answer my question: when I say "context" I mean
the loop context - not the option value that was selected. This I know
how to get, but I don't know for which loop item it refers.
Let's say I have a list of pens, and each can be red, blue or green:
${pen.id}
The penModel just models the three possible colors, penOption is the
selected color.
Now when a user makes a change, the onValueChangedFromPenSelect(Color
color) method is called.
No problem - but for which pen is it called? Without a loop context I do
not know this.
Given what you've said about value encoder, can I use this to store some
combination of both the pen id and the color id as the option value?
On Thu, 2011-02-24 at 12:34 -0300, Thiago H. de Paula Figueiredo wrote:
> On Thu, 24 Feb 2011 11:58:26 -0300, Richard Hill
> wrote:
>
> > Hi - again :)
>
> Hi!
>
> > I am supplying select and option models, which seem to work fine. But
> > how how do I supply a context? The t:select component does not appear to
> > take one. Without this I cannot know to what object my state change
> > relates.
>
> Have you read the Select component documentation?
> (http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Select.html).
> "The event handler method for the event valuechanged is used to provide
> the available car models of the currently selected car maker. The new
> Select's value is passed as context."
>
> public Object onValueChanged(CarMaker maker)
>
> In other words: you will receive the selected option as the event handler
> method parameter.
>
> > I've looked at valueencoders, but according to the docs, and from what
> > Thiago said yesterday, this seems to be alternative approach to using
> > models, which doesn't help.
>
> I haven't said that. ValueEncoder and SelectModel are not alternative
> approaches to do the same thing. They do different things: SelectModel
> provides the options (including labels) and ValueEncoder encodes them for
> the value attribute of the option tag.
>
> Here's the description from the SelectModel javadoc:
>
> "(SelectModel) Defines the possible options and option groups for a
> [X]HTML element.
>
> Primarily used by the Select component, but potentially used by anything
> similar, that needs to present a list of options to the user. Generally
> paired with a ValueEncoder to create client-side representations of
> server-side values."
>
> Please read the documentation before asking. ;)
>
Re: No context for a t:select?
On Thu, 24 Feb 2011 11:58:26 -0300, Richard Hill wrote: Hi - again :) Hi! I am supplying select and option models, which seem to work fine. But how how do I supply a context? The t:select component does not appear to take one. Without this I cannot know to what object my state change relates. Have you read the Select component documentation? (http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/Select.html). "The event handler method for the event valuechanged is used to provide the available car models of the currently selected car maker. The new Select's value is passed as context." public Object onValueChanged(CarMaker maker) In other words: you will receive the selected option as the event handler method parameter. I've looked at valueencoders, but according to the docs, and from what Thiago said yesterday, this seems to be alternative approach to using models, which doesn't help. I haven't said that. ValueEncoder and SelectModel are not alternative approaches to do the same thing. They do different things: SelectModel provides the options (including labels) and ValueEncoder encodes them for the value attribute of the option tag. Here's the description from the SelectModel javadoc: "(SelectModel) Defines the possible options and option groups for a [X]HTML element. Primarily used by the Select component, but potentially used by anything similar, that needs to present a list of options to the user. Generally paired with a ValueEncoder to create client-side representations of server-side values." Please read the documentation before asking. ;) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
