Hi all..
I'm trying to find a way to cleanup some of my existing code. I've got, in a handful of places, items coming out of a Glorpified database and use this data as the items in various Canvas API #select lists for various forms I've got. What I currently do is prepend an item to the front of the select array when the component is initially drawn by Seaside that has text similar to "Select one...".. I've got code that will take the array that I get back from Glorp and add a nil item to the front of the array that I can then check for in the labels: code block -- if the item being processed is nil, then I make the label say 'Select one...', otherwise use the database data.. Below is the code I use more or less to achieve this : html select list: orgs ; callback: [:i | self orgId: i]; labels: [:org | org = '' ifTrue: [ 'Select One..' ] ifFalse: [ org name ] ]. Does anyone use anything more elegant to overcome this or is everyone selecting their data directly from the database items without the need for a 'select one...' initially selected label? I'd love to ditch the code I've got that has to manipulate the array I get from Glorp along with the extra code to fiddle w/ Seaside labels to do what I want.. I guess I could take a stab at writing up a modification to the Canvas API's #select method that takes an #initiallySelectedLabel: method call to set the name for that initially selected label item -- would anyone else find that useful? Perhaps the result would allow for something like the following: html select list: orgs ; callback: [:i | self orgId: i]; labels: [:org | org name ]; initiallySelectedLabel: 'Select One...'. Comments? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
No, personally I would much rather see, _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Boris Popov wrote:
> No, personally I would much rather see, > > labels: [:o | o ifNil: [] ifNotNil: []]; > enablement: [:o | o notNil]; > > Its just a little more consistent, your suggestion seems very > specialized IMHO and this would still work and be readable. Boris -- you beat me.. (8-> I was just writing a reply indicating that your recent #enablement modification sounds like its in the same sort of area.. Oh well.. I guess I had forgotten about it until after I was poking around some more in WASelectTag.. Thanks for pointing it out! _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Rick Flower
2007/4/6, Rick Flower <[hidden email]>:
> Hi all.. > > I'm trying to find a way to cleanup some of my existing code. I've got, > in a handful of places, items coming out of a Glorpified database and > use this data as the items in various Canvas API #select lists for > various forms I've got. > > What I currently do is prepend an item to the front of the select array > when the component is initially drawn by Seaside that has text similar > to "Select one...".. I've got code that will take the array that I > get back from Glorp and add a nil item to the front of the array that I > can then check for in the labels: code block -- if the item being > processed is nil, then I make the label say 'Select one...', otherwise > use the database data.. Below is the code I use more or less to > achieve this : > > html select list: orgs ; > callback: [:i | self orgId: i]; > labels: [:org | org = '' ifTrue: [ 'Select One..' ] ifFalse: [ org name ] ]. > > Does anyone use anything more elegant to overcome this or is everyone > selecting their data directly from the database items without the need > for a 'select one...' initially selected label? I'd love to ditch the code > I've got that has to manipulate the array I get from Glorp along with the > extra code to fiddle w/ Seaside labels to do what I want.. > > I guess I could take a stab at writing up a modification to the Canvas > API's #select method that takes an #initiallySelectedLabel: method call > to set the name for that initially selected label item -- would anyone > else find that useful? Perhaps the result would allow for something like > the following: > > html select list: orgs ; > callback: [:i | self orgId: i]; > labels: [:org | org name ]; > initiallySelectedLabel: 'Select One...'. > > Comments? html select beOptional list: orgs; on: #orgId of: self; "You can use #name if you implement #value in Symbol You can leave this out of you implement #displayString or #renderOn. in your domain class" labels: [:org | org name ]; optionalLabel: 'Select One...'. Philippe > _______________________________________________ > 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 |
Philippe Marschall wrote:
> html select > beOptional > list: orgs; > on: #orgId of: self; > "You can use #name if you implement #value in Symbol > You can leave this out of you implement #displayString or > #renderOn. in your domain class" > labels: [:org | org name ]; > optionalLabel: 'Select One...'. Hmm.. I saw the "beOptional" but wasn't sure what it did -- is that just a flag that controls whether or not to use the optionalLabel or does it do something else as well? I did miss however the #optionalLabel: method. I'm not really sure what the #on: is doing -- it looks like an alternative to #callback -- any comments on why its better? Is that because I'm not specifying a #selected call and this one call does both? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
When I use a select tag and I specify beSubmitOnChange I would like to be
able to have a handler that works only when I click on that particular list. For example: html select list: self list; on: #selectedItem of: self; beSubmitOnClick; with: [ self triggerEvent: #changed with: self ] The with: block gets evaluated even if I do not actually click on anything in the list. Is there a way to have a handler that only gets evaluated when the user make a direct selection? -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> The with: block gets evaluated even if I do not actually click on anything
> in the list. Is there a way to have a handler that only gets evaluated > when the user make a direct selection? I meant to say that the with: block gets evaluated when the form is submitted, even if the submit came from some other component. I hope that's more clear. -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Rick Flower
2007/4/6, Rick Flower <[hidden email]>:
> Philippe Marschall wrote: > > > html select > > beOptional > > list: orgs; > > on: #orgId of: self; > > "You can use #name if you implement #value in Symbol > > You can leave this out of you implement #displayString or > > #renderOn. in your domain class" > > labels: [:org | org name ]; > > optionalLabel: 'Select One...'. > > > Hmm.. I saw the "beOptional" but wasn't sure what it did -- is that just > a flag that controls whether or not to use the optionalLabel or does it > do something else as well? I did miss however the #optionalLabel: > method. #beOptional adds a nil item to #list which has the semantic of no selection. #optionalLabel: is the label for nil. > I'm not really sure what the #on: is doing -- it looks like an > alternative to #callback -- any comments on why its better? Is that > because I'm not specifying a #selected call and this one call does both? It's not "better" it just saves the the #selected and #callback: You probably don't want to hear it but one of the many copy pasted (noone needs Traits in real applications anyway) should explain it: on: selector of: anObject self value: (anObject perform: selector). self callback: [ :value | anObject perform: selector asMutator with: value ] Philippe > _______________________________________________ > 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 |
Philippe Marschall wrote:
> #beOptional adds a nil item to #list which has the semantic of no > selection. #optionalLabel: is the label for nil. oohh.. Aaahhh.. That's what I'm looking for then.. With that, I should no longer need to fiddle with my array read from the Glorpilicious database.. Very good indeed.. It wasn't clear (to me -- a relative ST newbie) what the code in #optionsOn: was doing.. But in reviewing the code again, I see uses of a brush and optionalLabel.. I'll give it a whirl to see if it works as I expect.. >> I'm not really sure what the #on: is doing -- it looks like an >> alternative to #callback -- any comments on why its better? Is that >> because I'm not specifying a #selected call and this one call does both? > > It's not "better" it just saves the the #selected and #callback: > > You probably don't want to hear it but one of the many copy pasted > (noone needs Traits in real applications anyway) should explain it: > > on: selector of: anObject > self value: (anObject perform: selector). > self callback: [ :value | anObject perform: selector asMutator with: > value ] Yeah, I saw that code already which is why I asked if there was any obvious benefit -- it sounds like it's just shorter based on your comment. I'll give it a try as well.. Shorter code = easier to read code -- at least most of the time. (8-> _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Philippe Marschall
> (noone needs Traits in real applications anyway)
Indeed :) could you gave us some classes with duplication... we are making another study on traits _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2007/4/7, stephane ducasse <[hidden email]>:
> > (noone needs Traits in real applications anyway) > > Indeed :) > > could you gave us some classes with duplication... > we are making another study on traits (WAAnchorTag) WACollectionTag WACompound (WAFileUploadTag) WAFormInputTag WAOptionTag WASubmitButtonTag WAImageButtonTag #on:of: and #callback: (and #selected to a certain extent). You'll probably find more if you digg more. Then there is the whole attribute story highlighted several times by Lukas. iCal/vCard is similar where a component type can have different properties which can not be modeled very well with inheritance. (that would even be a use for stateful Traits) Then there is Audrioscrobbler (which acutally uses Traits). Where you have different kinds of charts like - top albums - top artists and weekly versions of each like - weekly top albums - weekly top artists Philippe > _______________________________________________ > 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 |
In reply to this post by Philippe Marschall
Philippe Marschall wrote:
> html select > beOptional > list: orgs; > on: #orgId of: self; > labels: [:org | org name ]; > optionalLabel: 'Select One...'. > Well.. This works fine for regular times when using regular callbacks but fails when using a liveCallback (care of SeasideAsync) as the index is off by 1.. I'll see about making a fix to do the right thing when I'm a bit less tired.. I guess we need to teach it about the use of beOptional and friends. Once that is done then it should work ok. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Rick Flower wrote:
> Philippe Marschall wrote: >> html select >> beOptional >> list: orgs; >> on: #orgId of: self; >> labels: [:org | org name ]; >> optionalLabel: 'Select One...'. >> > Well.. This works fine for regular times when using regular callbacks > but fails when using a liveCallback (care of SeasideAsync) as the > index is off by 1.. I'll see about making a fix to do the right thing > when I'm a bit less tired.. I guess we need to teach it about the use > of beOptional and friends. Once that is done then it should work ok. This version fixes the issue but only for single selections -- not multiples -- I've got no code that uses multiples currently and am not really sure what modifications need to be done at this point. Perhaps someone could make the relevant updates for that case? Anyway, below is the modified code -- feel free to change the logic, but it seems to work in my case. liveCallback: liveBlock | uri id realEach| id := self ensureId. liveBlock fixCallbackTemps. uri := canvas urlForLiveAction: [:event :h | | values value | values := event value asArray collect: [:each | (self isOptional) ifTrue: [ realEach := each asInteger - 1] ifFalse: [ realEach := each asInteger]. list at: realEach]. -- Rick _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 08 Apr 2007, at 09:19 , Rick Flower wrote: > OK -- here's a quick fix to the SeasideAsync version of > #liveCallback.. This version fixes the issue but only for single > selections -- not multiples -- I've got no code that uses multiples > currently and am not really sure what modifications need to be done > at this point. Perhaps someone could make the relevant updates for > that case? Anyway, below is the modified code -- feel free to > change the logic, but it seems to work in my case. Hi Rick, Thanks for the contribution. I just integrated your fix, see - VisualWorks Public Store : 2.6b1.61.0 - Squeak : SeasideAsync-mb.61.mcz I used a slightly different implementation so that it works also for multiple selections, although I have problems to imagine real situations where combining #beMultiple and #beOptional would make sense. Enjoy. Michel _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Philippe Marschall
Philippe Marschall wrote:
> iCal/vCard is similar where a component type can have different > properties which can not be modeled very well with inheritance. > (that would even be a use for stateful Traits) Exactly how are "stateful Traits" different from multiple inheritance? I can't see any conceptual difference at all. Thanks, Jason _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Michel Bany
Michel Bany wrote:
> > On 08 Apr 2007, at 09:19 , Rick Flower wrote: > >> OK -- here's a quick fix to the SeasideAsync version of >> #liveCallback.. This version fixes the issue but only for single >> selections -- not multiples -- I've got no code that uses multiples >> currently and am not really sure what modifications need to be done at >> this point. Perhaps someone could make the relevant updates for that >> case? Anyway, below is the modified code -- feel free to change the >> logic, but it seems to work in my case. > > Hi Rick, > Thanks for the contribution. I just integrated your fix, see > - VisualWorks Public Store : 2.6b1.61.0 > - Squeak : SeasideAsync-mb.61.mcz > I used a slightly different implementation so that it works also for > multiple selections, although I have problems to imagine real situations > where combining #beMultiple and #beOptional would make sense. Thanks Michel -- I'll try it out when I get a chance. -- Rick _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Michel Bany
Michel,
Latest SeasideScriptaculous seems to pre-req SeasideBase, which is either something new and hasn't been published, or just a little bugger and should be removed from pre-reqs list, I suspect the latter :) One can ignore the load warning in the meantime. Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Michel Bany > Sent: Friday, April 06, 2007 7:11 PM > To: Seaside - general discussion > Subject: Re: [Seaside] Usage of Canvas' #select and #labels > > > On 08 Apr 2007, at 09:19 , Rick Flower wrote: > > > OK -- here's a quick fix to the SeasideAsync version of > > #liveCallback.. This version fixes the issue but only for single > > selections -- not multiples -- I've got no code that uses multiples > > currently and am not really sure what modifications need to be done > > at this point. Perhaps someone could make the relevant updates for > > that case? Anyway, below is the modified code -- feel free to > > change the logic, but it seems to work in my case. > > Hi Rick, > Thanks for the contribution. I just integrated your fix, see > - VisualWorks Public Store : 2.6b1.61.0 > - Squeak : SeasideAsync-mb.61.mcz > I used a slightly different implementation so that it works also for > multiple selections, although I have problems to imagine real > situations where combining #beMultiple and #beOptional would make > Enjoy. > Michel > > > > _______________________________________________ > 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 |
Even worse, if I happen to have SeasideBase parcel somewhere in the
path, it loads fine, but the result is a herd of overrides of various kinds :) Cheers! -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Boris Popov > Sent: Friday, April 13, 2007 9:10 AM > To: Seaside - general discussion > Subject: RE: [Seaside] Usage of Canvas' #select and #labels > > Michel, > > Latest SeasideScriptaculous seems to pre-req SeasideBase, which is > either something new and hasn't been published, or just a little > and should be removed from pre-reqs list, I suspect the latter :) One > can ignore the load warning in the meantime. > > Cheers! > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. Unless otherwise indicated, it contains information that is > private and confidential. If you have received it in error, please > notify the sender and delete the entire message including any > attachments. > > Thank you. > > > -----Original Message----- > > From: [hidden email] [mailto:seaside- > > [hidden email]] On Behalf Of Michel Bany > > Sent: Friday, April 06, 2007 7:11 PM > > To: Seaside - general discussion > > Subject: Re: [Seaside] Usage of Canvas' #select and #labels > > > > > > On 08 Apr 2007, at 09:19 , Rick Flower wrote: > > > > > OK -- here's a quick fix to the SeasideAsync version of > > > #liveCallback.. This version fixes the issue but only for single > > > selections -- not multiples -- I've got no code that uses > > > currently and am not really sure what modifications need to be done > > > at this point. Perhaps someone could make the relevant updates for > > > that case? Anyway, below is the modified code -- feel free to > > > change the logic, but it seems to work in my case. > > > > Hi Rick, > > Thanks for the contribution. I just integrated your fix, see > > - VisualWorks Public Store : 2.6b1.61.0 > > - Squeak : SeasideAsync-mb.61.mcz > > I used a slightly different implementation so that it works also for > > multiple selections, although I have problems to imagine real > > situations where combining #beMultiple and #beOptional would make > sense. > > Enjoy. > > Michel > > > > > > > > _______________________________________________ > > 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 Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris Popov a écrit :
> Michel, > > Latest SeasideScriptaculous seems to pre-req SeasideBase, which is > either something new and hasn't been published, or just a little bugger > and should be removed from pre-reqs list, I suspect the latter :) One > can ignore the load warning in the meantime. > > Yes, this was a mistake from me and I fixed it. Sorry, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris Popov a écrit :
> Even worse, if I happen to have SeasideBase parcel somewhere in the > path, it loads fine, but the result is a herd of overrides of various > kinds :) > > Yes, I know that and this is why the pre-req should be absent when publishing to Store. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |