Question about WASelectTag class hierarchy...
Locked
Question about WASelectTag class hierarchy...
 
|
Hi all...
I was trying to fix a form (using the Canvas API) that wasn't specifying the #tabindex: to direct the browser how to deal with tab key presses & form fields. Anyway, I found that WASelectTag doesn't seem to know anything about #tabindex.. In looking further into the guts of how the classes were put together, I see that the #tabindex: belongs to WAFormInputTag, but that WASelectTag isn't related to that class (the hierarchy splits after WATagBrush).. Since WASelectTag is part of a form, shouldn't it be related to WAFormInputTag? Or, is this just a case of some missing method(s) in either WACollectionTag (parent of WASelectTag) or WASelectTag that should be implementing #tabindex:? Just thought I'd ask.. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
> Or, is this just a case of some missing method(s) in either
> WACollectionTag (parent of WASelectTag) or WASelectTag that should be > implementing #tabindex:? The problem with many attributes is that we can either put them into many specific tags or into the superclass of all tags. Either-way there are some drawbacks. If we put these attributes into many specific tags we have code duplication, if we put them into the superclass we provide an attribute that might not be available to all tags. The answer are Traits of course, that fit very well the XHTML attribute modules. Since the development of Seaside is going on in 3.9 I wonder if it would make sense to take advantage of that? If only Monticello would transparently load a flattened view into older images, I would certainly vote for going this way ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Rick Flower
Rick Flower a écrit :
> Hi all... > > I was trying to fix a form (using the Canvas API) that wasn't > specifying the #tabindex: to direct the browser how to deal with tab > key presses & form fields. Anyway, I found that WASelectTag doesn't > seem to know anything about #tabindex.. In looking further into the > guts of how the classes were put together, I see that the #tabindex: > belongs to WAFormInputTag, but that WASelectTag isn't related to that > class (the hierarchy splits after WATagBrush).. Since WASelectTag is > part of a form, shouldn't it be related to WAFormInputTag? > I believe that you spotted something that will need to be fixed. We have two different spelling for the same method - #tabindex: in WAFormInput, and - #tabIndex: in WATagBrush So we have to make two decisions - which one should be removed - what spelling I vote for WATagBrush>tabIndex: since we have WATagBrush>onChange: Cheers, Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Lukas Renggli
On Sat, 28 Apr 2007 1:31 am, Lukas Renggli wrote:
> The answer are Traits of course, that fit very well the XHTML > attribute modules. Since the development of Seaside is going on in 3.9 > I wonder if it would make sense to take advantage of that? Given that there are active ports to VW, Dolphin and GemStone, as well as many users on pre-3.9 Squeak, I'd strongly prefer that we stay away from Traits in Seaside. I understand that they can be flattened, but it might still lead us to make design decisions that favor Squeak 3.9 at the expense of other dialects, which I wouldn't want (and if it doesn't lead to such decisions, what good is it anyway?) Avi _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Rick Flower
Please don't do traits, we use VisualWorks and I would very much not want to load experimental code into our production environment. In this case I don't see a problem with code duplication. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Avi Bryant-2
I really don't see how Traits affect portability.
PackageInfo-Exporters just has to flatten them, that's dead simple, even I could do that. Same goes for the more broken Squeak versions (< 3.9): Cheers Philippe 2007/4/28, Avi Bryant <[hidden email]>: > On Sat, 28 Apr 2007 1:31 am, Lukas Renggli wrote: > > The answer are Traits of course, that fit very well the XHTML > > attribute modules. Since the development of Seaside is going on in 3.9 > > I wonder if it would make sense to take advantage of that? > > Given that there are active ports to VW, Dolphin and GemStone, as well > as many users on pre-3.9 Squeak, I'd strongly prefer that we stay away > from Traits in Seaside. I understand that they can be flattened, but it > might still lead us to make design decisions that favor Squeak 3.9 at > the expense of other dialects, which I wouldn't want (and if it doesn't > lead to such decisions, what good is it anyway?) > > Avi > _______________________________________________ > 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 |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
How do you load experimental code into VisualWorks nowadays?
Cheers Philippe 2007/4/28, Boris Popov <[hidden email]>: > > > > Please don't do traits, we use VisualWorks and I would very much not want to > load experimental code into our production environment. In this case I don't > see a problem with code duplication. > > Cheers! > > -Boris > (Sent from a BlackBerry) > > ----- Original Message ----- > From: [hidden email] > <[hidden email]> > To: Seaside - general discussion > <[hidden email]> > Sent: Sat Apr 28 01:31:13 2007 > Subject: Re: [Seaside] Question about WASelectTag class hierarchy... > > > Or, is this just a case of some missing method(s) in either > > WACollectionTag (parent of WASelectTag) or WASelectTag that should be > > implementing #tabindex:? > > The problem with many attributes is that we can either put them into > many specific tags or into the superclass of all tags. Either-way > there are some drawbacks. If we put these attributes into many > specific tags we have code duplication, if we put them into the > superclass we provide an attribute that might not be available to all > tags. > > The answer are Traits of course, that fit very well the XHTML > attribute modules. Since the development of Seaside is going on in 3.9 > I wonder if it would make sense to take advantage of that? If only > Monticello would transparently load a flattened view into older > images, I would certainly vote for going this way ... > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > 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 |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Rick Flower
There's traits for VW. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Rick Flower
But would they work in all other dialects without any adverse effects? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
Yes, because there won't be any traits anymore once they flattened.
Cheers Philippe 2007/4/28, Boris Popov <[hidden email]>: > > > > But would they work in all other dialects without any adverse effects? > > Cheers! > > -Boris > (Sent from a BlackBerry) > > ----- Original Message ----- > From: [hidden email] > <[hidden email]> > To: Seaside - general discussion > <[hidden email]> > Sent: Sat Apr 28 09:03:03 2007 > Subject: Re: [Seaside] Question about WASelectTag class hierarchy... > > I really don't see how Traits affect portability. > PackageInfo-Exporters just has to flatten them, that's dead simple, > even I could do that. Same goes for the more broken Squeak versions (< > 3.9): > > Cheers > Philippe > > 2007/4/28, Avi Bryant <[hidden email]>: > > On Sat, 28 Apr 2007 1:31 am, Lukas Renggli wrote: > > > The answer are Traits of course, that fit very well the XHTML > > > attribute modules. Since the development of Seaside is going on in 3.9 > > > I wonder if it would make sense to take advantage of that? > > > > Given that there are active ports to VW, Dolphin and GemStone, as well > > as many users on pre-3.9 Squeak, I'd strongly prefer that we stay away > > from Traits in Seaside. I understand that they can be flattened, but it > > might still lead us to make design decisions that favor Squeak 3.9 at > > the expense of other dialects, which I wouldn't want (and if it doesn't > > lead to such decisions, what good is it anyway?) > > > > Avi > > _______________________________________________ > > 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 > > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Michel Bany-3
Michel Bany wrote:
> I believe that you spotted something that will need to be fixed. > We have two different spelling for the same method > - #tabindex: in WAFormInput, and > - #tabIndex: in WATagBrush > So we have to make two decisions > - which one should be removed > - what spelling I had noticed that as well when I was searching through the image but didn't actually see it until you pointed it out.. If we change to #tabIndex, won't that effect backwards compatability? Either way works for me as my breakage won't be that big.. Of course, it seems many are interested in traits, but I've got no idea what they are -- perhaps that needs more though? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
> > We have two different spelling for the same method
> > - #tabindex: in WAFormInput, and > > - #tabIndex: in WATagBrush I removed #tabindex: from WAFormInput in 2.8. #tabIndex: and #accessKey: (from the XHTML keyboard modules) are now defined in WATagBrush. It is the responsibility of the developer to not use these attributes for tags that do not support it. Maybe somebody can deprecate #tabindex: in 2.7? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Philippe Marschall
Yeap!
> I really don't see how Traits affect portability. > PackageInfo-Exporters just has to flatten them, that's dead simple, > even I could do that. Same goes for the more broken Squeak versions (< > 3.9): > > Cheers > Philippe > > 2007/4/28, Avi Bryant <[hidden email]>: >> On Sat, 28 Apr 2007 1:31 am, Lukas Renggli wrote: >> > The answer are Traits of course, that fit very well the XHTML >> > attribute modules. Since the development of Seaside is going on >> in 3.9 >> > I wonder if it would make sense to take advantage of that? >> >> Given that there are active ports to VW, Dolphin and GemStone, as >> well >> as many users on pre-3.9 Squeak, I'd strongly prefer that we stay >> away >> from Traits in Seaside. I understand that they can be flattened, >> but it >> might still lead us to make design decisions that favor Squeak 3.9 at >> the expense of other dialects, which I wouldn't want (and if it >> doesn't >> lead to such decisions, what good is it anyway?) >> >> Avi >> _______________________________________________ >> 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 |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Philippe Marschall
Philippe Marschall wrote:
> Yes, because there won't be any traits anymore once they flattened. Did we ever come up with a suggested solution here that everyone is happy with? I've got no idea what traits are so I'm going to leave that to the rest of you. I guess for the time being I'll build an override of my own that allows me to get around this for now.. I think I read that someone (Lukas?) was suggesting to get rid of #tabindex: in favor of #tabIndex: to better align with other multi-word method names -- correct? Thanks! _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
> I think I read that someone (Lukas?) was suggesting to get rid of
> #tabindex: in favor of #tabIndex: to better align with other multi-word > method names -- correct? Yes, there is a WATagBrush>>#tabIndex: in 2.8. The other implementations of #tabindex: have been removed. I think that fits the best with the rest of the framework. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Rick Flower
traits are group of methods that you can compose/reuse in classes to
avoid duplicated code. They are just like first class method categories. Stef On 29 avr. 07, at 18:58, Rick Flower wrote: > Philippe Marschall wrote: >> Yes, because there won't be any traits anymore once they flattened. > > Did we ever come up with a suggested solution here that everyone is > happy with? I've got no idea what traits are so I'm going to leave > that to the rest of you. I guess for the time being I'll build an > override of my own that allows me to get around this for now.. > > I think I read that someone (Lukas?) was suggesting to get rid of > #tabindex: in favor of #tabIndex: to better align with other multi- > word method names -- correct? > > Thanks! > _______________________________________________ > 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 |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Rick Flower
But if they get flattened for ports anyway, does it really matter if you use them or not? In which case why bother? Wouldn't you rather auto generate all accessors from the DTD? :) _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
2007/4/29, Boris Popov <[hidden email]>:
> > > > But if they get flattened for ports anyway, does it really matter if you use > them or not? In which case why bother? This is what I'm trying to say. I can't see how it affects anybody but developers. > Wouldn't you rather auto generate all > accessors from the DTD? :) Sucky (C-like) attribute names like href. A lot of the methods in WAHtmlCanvas were actually generated. Cheers Philippe > Cheers! > > -Boris > (Sent from a BlackBerry) > > ----- Original Message ----- > From: [hidden email] > <[hidden email]> > To: Seaside - general discussion > <[hidden email]> > Sent: Sun Apr 29 13:30:46 2007 > Subject: Re: [Seaside] Question about WASelectTag class hierarchy... > > traits are group of methods that you can compose/reuse in classes to > avoid duplicated code. > They are just like first class method categories. > > Stef > > On 29 avr. 07, at 18:58, Rick Flower wrote: > > > Philippe Marschall wrote: > >> Yes, because there won't be any traits anymore once they flattened. > > > > Did we ever come up with a suggested solution here that everyone is > > happy with? I've got no idea what traits are so I'm going to leave > > that to the rest of you. I guess for the time being I'll build an > > override of my own that allows me to get around this for now.. > > > > I think I read that someone (Lukas?) was suggesting to get rid of > > #tabindex: in favor of #tabIndex: to better align with other multi- > > word method names -- correct? > > > > Thanks! > > _______________________________________________ > > 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 > > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
In reply to this post by Rick Flower
On the other hand if someone has html reference handy and you're looking for href and can't find it things might get frustrating for some. Either way, that's a discussion outside of the subject. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Question about WASelectTag class hierarchy...
|
|
2007/4/29, Boris Popov <[hidden email]>:
> > > > On the other hand if someone has html reference handy and you're looking for > href and can't find it things might get frustrating for some. Either way, > that's a discussion outside of the subject. You can still do Ctrl+shift+e on 'href' Cheers Philippe > Cheers! > > -Boris > (Sent from a BlackBerry) > > ----- Original Message ----- > From: [hidden email] > <[hidden email]> > To: Seaside - general discussion > <[hidden email]> > Sent: Sun Apr 29 13:57:06 2007 > Subject: Re: [Seaside] Question about WASelectTag class hierarchy... > > 2007/4/29, Boris Popov <[hidden email]>: > > > > > > > > But if they get flattened for ports anyway, does it really matter if you > use > > them or not? In which case why bother? > > This is what I'm trying to say. I can't see how it affects anybody but > developers. > > > Wouldn't you rather auto generate all > > accessors from the DTD? :) > > Sucky (C-like) attribute names like href. A lot of the methods in > WAHtmlCanvas were actually generated. > > Cheers > Philippe > > > Cheers! > > > > -Boris > > (Sent from a BlackBerry) > > > > ----- Original Message ----- > > From: [hidden email] > > <[hidden email]> > > To: Seaside - general discussion > > <[hidden email]> > > Sent: Sun Apr 29 13:30:46 2007 > > Subject: Re: [Seaside] Question about WASelectTag class hierarchy... > > > > traits are group of methods that you can compose/reuse in classes to > > avoid duplicated code. > > They are just like first class method categories. > > > > Stef > > > > On 29 avr. 07, at 18:58, Rick Flower wrote: > > > > > Philippe Marschall wrote: > > >> Yes, because there won't be any traits anymore once they flattened. > > > > > > Did we ever come up with a suggested solution here that everyone is > > > happy with? I've got no idea what traits are so I'm going to leave > > > that to the rest of you. I guess for the time being I'll build an > > > override of my own that allows me to get around this for now.. > > > > > > I think I read that someone (Lukas?) was suggesting to get rid of > > > #tabindex: in favor of #tabIndex: to better align with other multi- > > > word method names -- correct? > > > > > > Thanks! > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > 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 |
| Free forum by Nabble | Edit this page |