Feature or bug related to Canvas API's implementation of textInput (async edition)?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature or bug related to Canvas API's implementation of textInput (async edition)?

Rick Flower
I just happened to notice this when I had a breakpoint set inside a
liveCallback block such as below :

(html textInput) size: 5; value: ''; liveCallback: [ :value :r |
dosomething_here ]

I find that a breakpoint fires every time a character is typed into the
field.. I'm guessing (but haven't
checked) that the javascript as part of SeasideAsync is hooked into the
javascript "onchange" event
instead of a focus change..   Anyway, just thought I'd check to see if
this would still work if plugged
into the focus change event instead without pestering Seaside for each
character.  Anyway, just
thought I'd check..




_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Feature or bug related to Canvas API's implementation of textInput (async edition)?

Michel Bany

On 31 Jan 2007, at 08:25 , Rick Flower wrote:

> I just happened to notice this when I had a breakpoint set inside a  
> liveCallback block such as below :
>
> (html textInput) size: 5; value: ''; liveCallback: [ :value :r |  
> dosomething_here ]
>
> I find that a breakpoint fires every time a character is typed into  
> the field.. I'm guessing (but haven't
> checked) that the javascript as part of SeasideAsync is hooked into  
> the javascript "onchange" event
> instead of a focus change..   Anyway, just thought I'd check to see  
> if this would still work if plugged
> into the focus change event instead without pestering Seaside for  
> each character.  Anyway, just
> thought I'd check..

Definitely a feature, not a bug, see the last paragraph at
http://www.cincomsmalltalk.com/userblogs/avi/blogView?entry=3268075684

The javascript is attached to the "keydown"/"keypress" event  
depending on the browser.
You can see the effect at http://localhost:8008/seaside/go/tests/ 
async/canvas/livetests

Cheers,
Michel


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: Feature or bug related to Canvas API's implementationof textInput (async edition)?

Ron Teitelbaum
I agree, I use it for a zipCode lookup and it's much better to get feedback
as you type instead of making the user leave the field first.

Ron Teitelbaum

> From: Michel Bany
> Sent: Wednesday, January 31, 2007 8:24 AM
>
> On 31 Jan 2007, at 08:25 , Rick Flower wrote:
>
> > I just happened to notice this when I had a breakpoint set inside a
> > liveCallback block such as below :
> >
> > (html textInput) size: 5; value: ''; liveCallback: [ :value :r |
> > dosomething_here ]
> >
> > I find that a breakpoint fires every time a character is typed into
> > the field.. I'm guessing (but haven't
> > checked) that the javascript as part of SeasideAsync is hooked into
> > the javascript "onchange" event
> > instead of a focus change..   Anyway, just thought I'd check to see
> > if this would still work if plugged
> > into the focus change event instead without pestering Seaside for
> > each character.  Anyway, just
> > thought I'd check..
>
> Definitely a feature, not a bug, see the last paragraph at
> http://www.cincomsmalltalk.com/userblogs/avi/blogView?entry=3268075684
>
> The javascript is attached to the "keydown"/"keypress" event
> depending on the browser.
> You can see the effect at http://localhost:8008/seaside/go/tests/
> async/canvas/livetests
>
> Cheers,
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Feature or bug related to Canvas API's implementationof textInput (async edition)?

Rick Flower
Ron Teitelbaum wrote:
> I agree, I use it for a zipCode lookup and it's much better to get feedback
> as you type instead of making the user leave the field first.

Thanks for the replies Ron & Michel.. I was just wondering if that was
the expected behavior.. It wasn't what I was expecting, but now I know
better.

Ron -- Your example sounds like a nice way to use this feature.. Pretty
cool!
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Feature or bug related to Canvas API's implementation of textInput (async edition)?

Ramon Leon-4
In reply to this post by Rick Flower
> I just happened to notice this when I had a breakpoint set inside a
> liveCallback block such as below :
>
> (html textInput) size: 5; value: ''; liveCallback: [ :value :r |
> dosomething_here ]
>
> I find that a breakpoint fires every time a character is typed into the
> field.. I'm guessing (but haven't
> checked) that the javascript as part of SeasideAsync is hooked into the
> javascript "onchange" event
> instead of a focus change..   Anyway, just thought I'd check to see if
> this would still work if plugged
> into the focus change event instead without pestering Seaside for each
> character.  Anyway, just
> thought I'd check..
>
> Rick Flower wrote:

Another reason I prefer Scriptaculous, I decide what client side event
fires my callback.  I can seamlessly compose new and unique solutions to
problems by mixing and matching client side and server side code as if
there weren't a difference.

(html textInput)
     id: #textId; size: 5; value: '';
     callback: [:value | self textId: value];
     onBlur: (html updater
                  triggerFormElement: #textId;
                  callback: [:ajax | dosomething_here ]

And the metaphor couldn't be simpler, it matches exactly how you'd
program in javascript, you'd attach code to event handlers of html tags,
just like here.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Feature or bug related to Canvas API's implementation of textInput (async edition)?

Michel Bany


> Another reason I prefer Scriptaculous, I decide what client side  
> event fires my callback.

Hi Ramon,

Yes, SeasideAsync can do that too.

(html textInput)
        id: #textId; size: 5; value: ''
        callback: [:value | self textId: value];
        forEvent: 'onblur' callback: [ :event :r | dosomething ];
        forEvent: 'onblur' callback: [ :event :r | dosomemore onblur stuff ];
        forEvent: 'onfocus' callback: [ :event :r | doevenmore ];
        etc.

Some conveniency methods already exist in WATagBrush

onFocusCallback: aBlock
        self forEvent: 'onfocus' callback: aBlock

onClickCallback: aBlock
        self forEvent: 'onclick' callback: aBlock

That said, yes, I agree that Scriptcalous is a lot more comprehensive
and so much more powerful. But it is also more difficult to use, since
you need to have a good understanding of javascript to use it.

With SeasideAsync you just need to understand what a live callback
is and it is very close to what a regular Seaside callback is. I  
personally
dedicate some of my time to maintain the SeasideAsync package so
that some of my customers can do Ajax without learning Javascript.

I am also doing my best to make sure that SeasideAsync and Scriptaculous
can work together in the same component, so that Seasiders can make
their own choice.

Cheers,
Michel.





_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside