Smalltalk › Frameworks & Tools › Seaside › Seaside Development

broken SU

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Julian Fitzell-2

broken SU

So I looked into the failing Scriptaculous code. The problem is that
we are now adding onclick handlers for scriptaculous AJAX calls using
the observe() function. Returning false from these handlers does not
prevent the anchor's normal action from executing. Instead of "return
false" you need "event.stop()".

So, how do we solve that? We don't want users to have to know how
Seaside is adding the event handler in order to know what code they
need to write. Where's the right place to put an abstraction for this
(and can it be shared between SU/JQ?). Do we define some variant of
#callback: that doesn't allow the normal action to take place? (or a
variant that takes a boolean - #callback:stop:?)

I think we need to fix this before releasing because a bunch of the
demos are just totally broken (at very least, we need to change all
the "return false" statements to use "event.stop()" but that's not
really a proper fix).

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian Fitzell-2

Re: broken SU

Or a method on JSObject called #stopHandling or something?

onClick: (html scriptaculous updater
id: id;
callback: [ ... ];
stopHandling)

Not sure how it gets the context though - do JSObjects know the Document?

Julian

On Wed, May 26, 2010 at 12:35 AM, Julian Fitzell <[hidden email]> wrote:

> So I looked into the failing Scriptaculous code. The problem is that
> we are now adding onclick handlers for scriptaculous AJAX calls using
> the observe() function. Returning false from these handlers does not
> prevent the anchor's normal action from executing. Instead of "return
> false" you need "event.stop()".
>
> So, how do we solve that? We don't want users to have to know how
> Seaside is adding the event handler in order to know what code they
> need to write. Where's the right place to put an abstraction for this
> (and can it be shared between SU/JQ?). Do we define some variant of
> #callback: that doesn't allow the normal action to take place? (or a
> variant that takes a boolean - #callback:stop:?)
>
> I think we need to fix this before releasing because a bunch of the
> demos are just totally broken (at very least, we need to change all
> the "return false" statements to use "event.stop()" but that's not
> really a proper fix).
>
> Julian
>

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

Nick

Re: broken SU

In reply to this post by Julian Fitzell-2

I investigated this with Julian. Apologies for reiterating some of the ground already covered:

SUAllComponentTests class>>initialize

..... preferenceAt: #scriptGeneratorClass put: PTScriptGenerator

with a PTScriptGenerator anchors which contain an href and onclick handlers AND use "return false" in onClick to stop the href link from firing do not work as expected - The href link is activated. This is causing at least SUAccordion and SUCarousel to break in the current trunk. The problem can be fixed by replacing "return false" with "event.stop()".

(WADispatcher default handlerAt: 'javascript/scriptaculous-components') preferenceAt: #scriptGeneratorClass put: nil

results in working SUAccordion and SUCarousel without code changes.

(WADispatcher default handlerAt: 'javascript/scriptaculous-components') preferenceAt: #scriptGeneratorClass put: nil

and using the "event.stop()" code change also works.

a potential problem arises for users, with existing Scriptaculous code that use say SUUpdater in an onclick handler on an anchor with an href. When they update to the latest code alls well provided they don't start using PTScriptGenerator, in which case they have to change their "return false" to "event.stop()"

thoughts?

Nick

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