Thanks for answer, Koen.
Koen Deforche wrote:
> We have a longstanding discussions about what Wt should be doing for
> these situations.
>
> There are some options:
>
> a) a simple, effective, solution would be to (always) ignore any event
> while the previous response has not been received yet (like you
> suggest). But the event is simply discarded, so the user will at least
> be surprised.
>
> b) to solve this, we could queue events until the previous response
> has been received. This in fact, does not solve the problem, because
> you could still have two clicks on a button that is supposed to
> disappear after the first click.
> c) we could complicate the API with a flag that allows the developer
> to indicate whether subsequent events should be cancelled, but, this
> would not be more work than:
>
> d) give responsibility to the developer to make sure a button cannot
> be clicked twice. He could that that by:
>
> 1) client-side: use WWidget::hide() or WWidget::disable()
>
> WPushButton *b = ...
> b->clicked.connect(SLOT(b, WWidget::hide));
> // or perhaps nicer: b->clicked.connect(SLOT(b, WWidget::disable));
> b->clicked.connect(SLOT(this, MyWidget::doStuff));
>
> Because hide() and disable() are stateless slots, they are optimized
> in client-side code that runs immediately when the button is clicked.
> The server-side slot, doStuff() could then show() or enable() the
> button again if he wishes.
>
It seems that this will work, but code will fill with unpleasant hide/shows.
And what is worst, the slot code could have no button context (it
doesn't know who has called him) - right as my application is
implemented, so it
won't be able to re-enable button before return...
> 2) server-side: delete the widget that originated the signal (and
> perhaps recreate it).
>
> button_ = new WPushButton(...);
> button_->clicked.connect(SLOT(this, MyWidget::doStuff));
>
> void MyWidget::doStuff()
> {
> // do stuff...
> delete button_;
> }
>
> This works because your application will process events one after the
> other, and, the second event will no longer be valid ("exposed in Wt
> talk") because the clicked Signal got deleted together with the
> button.
>
Actually, I experienced some sporadic SEGFAULTS when dealing with delete
operator on elements in running application.
It seems that some thread tries to operate on already deleted object.
Maybe this issue is somehow tied to subj.
I had no time to investigate, so I store all pointers in set and then
delete them in application destructor.
So this approach is not suitable right now.
And again, Slot code has no button context.
> All in all, I am in favor of option d). But, admittedly, this needs to
> be documented somewhere! And, perhaps I am wrong about the
> effectiveness of the two solutions?
>
As i understand, Wt keeps DOM on server side as well.
Could it perform checks before giving response to client - some sort of
"Does the element that participates in operation still in DOM?" and
queuing that response.
Also, it should preserve the correct order of responses to avoid
situations, when request 2 is served before request 1 (can it be the
source of this problem?).
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
