Suggested extension for WASelectTag
Locked
 
|
Hi,
I needed a way to add an attribute of each option in a select list, because Seaside uses the value attribute for its server side callback. The reason was I wanted to do something on the browser side onChange/onKeyUp based on some business values. Here is what I changed in WASelectTag: * added inst var: itemConfigBlock with getter and setter * changed #renderListItemLabelled: to renderListItem: anObject labelled: aString | option | option := canvas option. self hasCallback ifTrue: [option value: (self valueFor: anObject)]. titleBlock isNil ifFalse: [option title: (self titleFor: anObject)]. itemConfigBlock ifNotNil: [:block | block value: option value: anObject]. option selected: (self isSelected: anObject); disabled: (self isEnabled: anObject) not; with: aString And this is how you can use it: html select items: MyListOfItems; callback: []; itemConfigBlock: [:option :anObject| option attrbibuteAt: 'data-value' put: anObject someValue asString]. Was this available already and did I overlook it? Does this sound reasonable? Worth adding to Seaside? Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Suggested extension for WASelectTag
|
|
Hi Joachim,
I don't think you missed an existing way to set an attribute on a select tag option. Other than iterating over the options like in e.g. WAInputElementContainer>>#renderSingleSelectionCustomOn: I don't know how to set them. Seems like your method is more convenient than iterating over the option tags. I'd add it for sure. Paul
|
Re: Suggested extension for WASelectTag
|
|
In reply to this post by jtuchel
On Sat, Jul 1, 2017 at 2:24 AM, [hidden email] <[hidden email]> wrote: -- Hi, Yes, I had to do exactly the same. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Paul DeBruicker
Hi Paul,
I I admit not having invested too much time into the iteration possibility, I just couldn't get it to work. For some reason I couldn't get the combination of a callback for the select tag and setting value: on each option to work. I don't remember the datails, but I tried two or three ways and failed every time. I may have given up too fast, because the solution I suggested is so easy and fast to implement... My favorite solution wouldn't be adding a new attribute to each option tag, but using the value attribute of the options for the business value. OTOH, the two argument block also allows for disabling options or any other manipulation of an option, so it's quite flexible. I'll take a look at WAInputElementContainer>>#renderSingleSelectionCustomOn: and see what I have missed in my attempts. Thanks for the pointer. Joachim Am 02.07.17 um 18:34 schrieb Paul DeBruicker: > Hi Joachim, > > I don't think you missed an existing way to set an attribute on a select tag > option. Other than iterating over the options like in e.g. > WAInputElementContainer>>#renderSingleSelectionCustomOn: I don't know how to > set them. > > > Seems like your method is more convenient than iterating over the option > tags. I'd add it for sure. > > > Paul > > > > jtuchel wrote >> Hi, >> >> >> I needed a way to add an attribute of each option in a select list, >> because Seaside uses the value attribute for its server side callback. >> >> The reason was I wanted to do something on the browser side >> onChange/onKeyUp based on some business values. >> >> >> Here is what I changed in WASelectTag: >> >> * added inst var: itemConfigBlock with getter and setter >> >> * changed #renderListItemLabelled: to >> >> >> renderListItem: anObject labelled: aString >> >> | option | >> >> option := canvas option. >> self hasCallback ifTrue: [option value: (self valueFor: anObject)]. >> titleBlock isNil ifFalse: [option title: (self titleFor: anObject)]. >> itemConfigBlock ifNotNil: [:block | block value: option value: >> anObject]. >> option >> selected: (self isSelected: anObject); >> disabled: (self isEnabled: anObject) not; >> with: aString >> >> >> And this is how you can use it: >> >> >> html select >> >> items: MyListOfItems; >> >> callback: []; >> >> itemConfigBlock: [:option :anObject| option attrbibuteAt: >> 'data-value' put: anObject someValue asString]. >> >> >> Was this available already and did I overlook it? >> >> Does this sound reasonable? Worth adding to Seaside? >> >> >> Joachim >> >> >> >> >> >> >> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto: >> jtuchel@ >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> _______________________________________________ >> seaside mailing list >> seaside@.squeakfoundation >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > -- > View this message in context: http://forum.world.st/Suggested-extension-for-WASelectTag-tp4953167p4953223.html > Sent from the Seaside General mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Suggested extension for WASelectTag
|
|
In reply to this post by Mariano Martinez Peck
Hi guys,
I would prefer that Seaside is able to do this: html select callback: …; with:[ myItems do:[:anItem | html option attributeAt: … put: …; value: anItem ] ] Right now, you must do it like this (i.e. add a callback for each option): html select dispatchCallback; with:[ myItems do:[:anItem | html option attributeAt: … put: …; callback: [ …. ] value: anItem ] ] cheers, Johan
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Johan,
so #dispatchCallback was my missing piece... Thanks! I agree with your preference, for cases where you want to iterate over myItems. This sure would be a nicer API than what we have now. Joachim Am 03.07.17 um 09:19 schrieb Johan Brichau: Hi guys,
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Suggested extension for WASelectTag
|
|
In reply to this post by jtuchel
On Sat, Jul 1, 2017 at 7:24 AM, [hidden email]
<[hidden email]> wrote: > ... > > Was this available already and did I overlook it? Not that I know of. > Does this sound reasonable? Worth adding to Seaside? I have some issues with the API: - Config is an abbreviation, we don't usually use abbreviations - we don't usually use the Block suffix for methods that accept blocks, e.g.. #callback: not #callbackBlock:, see also #titles: (WAIframeTag >> #rootBlock is a bad example) I don't really have a good proposal, maybe #optionRenderer: but the renderer wouldn't render the whole option, only customize it. As Paul has noted if you want full control you may be better off rendering the the options yourself as done in WAInputElementContainer>>#renderSingleSelectionCustomOn [1] [1] https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-Tests-Functional.package/WAInputElementContainer.class/instance/renderSingleSelectionCustomOn..st Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Philippe,
Am 03.07.17 um 18:23 schrieb Philippe Marschall: > On Sat, Jul 1, 2017 at 7:24 AM, [hidden email] > <[hidden email]> wrote: >> ... >> >> Was this available already and did I overlook it? > Not that I know of. glad to hear that. Wouldn't be the first time, however ;-) >> Does this sound reasonable? Worth adding to Seaside? > I have some issues with the API: > - Config is an abbreviation, we don't usually use abbreviations > - we don't usually use the Block suffix for methods that accept > blocks, e.g.. #callback: not #callbackBlock:, see also #titles: > (WAIframeTag >> #rootBlock is a bad example) Yeah, I can live with that. I just couldn't come up with a good name ;-) > I don't really have a good proposal, maybe #optionRenderer: but the > renderer wouldn't render the whole option, only customize it. Well, the name is good as it describes what the block does. Renderer, however, is already a name with a meaning in Seaside and it is not a Block. > As Paul has noted if you want full control you may be better off > rendering the the options yourself as done in > WAInputElementContainer>>#renderSingleSelectionCustomOn [1] I already mentioned it in an answer to Johan: I was missing #dispatchCallback, and so couldn't make this work. However, if we have #labels: et al in WASelectTag, why not have a respective API for manipulation options individually. Nevertheless, I will most likely remove my extension from my local image and try the iteration thing now that I know how to get things going with dispatchCallback. > > [1] https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-Tests-Functional.package/WAInputElementContainer.class/instance/renderSingleSelectionCustomOn..st Thanks for the link. I cannot run Pharo 5/6 on my Mac since I upgraded to Sierra and the method is not available in VAST ;-) Best, Joachim > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Suggested extension for WASelectTag
|
|
Joachim - if you can’t run on your Mac that sounds like you need to either put Pharo in the applications directory (it needs a proper cert to live elsewhere and that hasn’t been done yet) OR run it from the terminal and use the zeroconf setup (which actually I find runs better).
Tim > On 3 Jul 2017, at 18:07, [hidden email] wrote: > > Philippe, > > > > Am 03.07.17 um 18:23 schrieb Philippe Marschall: >> On Sat, Jul 1, 2017 at 7:24 AM, [hidden email] >> <[hidden email]> wrote: >>> ... >>> >>> Was this available already and did I overlook it? >> Not that I know of. > glad to hear that. Wouldn't be the first time, however ;-) > >>> Does this sound reasonable? Worth adding to Seaside? >> I have some issues with the API: >> - Config is an abbreviation, we don't usually use abbreviations >> - we don't usually use the Block suffix for methods that accept >> blocks, e.g.. #callback: not #callbackBlock:, see also #titles: >> (WAIframeTag >> #rootBlock is a bad example) > Yeah, I can live with that. I just couldn't come up with a good name ;-) > >> I don't really have a good proposal, maybe #optionRenderer: but the >> renderer wouldn't render the whole option, only customize it. > Well, the name is good as it describes what the block does. Renderer, however, is already a name with a meaning in Seaside and it is not a Block. > > >> As Paul has noted if you want full control you may be better off >> rendering the the options yourself as done in >> WAInputElementContainer>>#renderSingleSelectionCustomOn [1] > I already mentioned it in an answer to Johan: I was missing #dispatchCallback, and so couldn't make this work. > However, if we have #labels: et al in WASelectTag, why not have a respective API for manipulation options individually. > Nevertheless, I will most likely remove my extension from my local image and try the iteration thing now that I know how to get things going with dispatchCallback. >> >> [1] https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-Tests-Functional.package/WAInputElementContainer.class/instance/renderSingleSelectionCustomOn..st > > Thanks for the link. I cannot run Pharo 5/6 on my Mac since I upgraded to Sierra and the method is not available in VAST ;-) > > Best, > > Joachim > > > > > >> >> Cheers >> Philippe >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:[hidden email] > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |