Seaside305 in Squeak 4.2
Locked
 
|
Original discussion on seaside list (now cc'ing Pharo list too)
Phillipe wrote on seaside list: >In general we use the OmniBrowser from [1], but it has issues in Pharo >1.2 as well :-( AFAIK these issues have been addressed and there is a Pharo specific OB version which is now hosted at squeaksource.com/PharoOB.html It is also used to build Pharo 1.2 already. For details ask Guillermo Polito or on Pharo-dev list. Lukas wrote: >I have a nicely working version of OB with RB, Shout and eCompletion >for Pharo 1.2. Just add <http://source.lukas-renggli.ch/pharo12 So you forked again and I wonder why? Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
[2.8]Slow connection causes problem
|
|
When I access my Seaside application using my iPhone over a 3G connection it is very easy to click on an anchor and then click on it or another anchor before I get a response. This often becomes a problem because the underlying state of my application is no longer valid for the second click. Clearly it makes sense for Seaside to handle this intelligently.
-Carl Gundel http://www.runbasic.com http://www.libertybasic.com_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: [2.8]Slow connection causes problem
|
|
Hi Carl
Until a better solution is found, what you can do is implement a script on WATagBrush manageMultipleClicks ^'if(this.enabled == false) { alert ("This request has already been submitted..."); return false;} else { this.enabled = false; }' and call that from WAAnchorTag, by overriding callback: callback: aNiladicValuable self onClick: self manageMultipleClicks. aNiladicValuable argumentCount > 0 ifTrue: [Grease.GRInvalidArgumentCount signal: 'Anchors expect a niladic callback.']. self url addField: (self storeCallback: (Seaside.WAActionCallback on: aNiladicValuable)) We've overidden callback in WASubmitButtonTag as well: callback: aNiladicValuable self onClick: self manageMultipleClicks. aNiladicValuable argumentCount > 0 ifTrue: [Grease.GRInvalidArgumentCount signal: 'Submit buttons expect a niladic callback.']. self name: (self storeCallback: (Seaside.WAActionCallback on: aNiladicValuable)) (that's the VW implementation of the callback, where we just added the script at the top) HTH Liliana -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Carl Gundel Sent: 08 March 2011 05:06 To: Seaside - general discussion Subject: [Seaside] [2.8]Slow connection causes problem When I access my Seaside application using my iPhone over a 3G connection it is very easy to click on an anchor and then click on it or another anchor before I get a response. This often becomes a problem because the underlying state of my application is no longer valid for the second click. Clearly it makes sense for Seaside to handle this intelligently. -Carl Gundel http://www.runbasic.com http://www.libertybasic.com_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside This e-mail is subject to a disclaimer, available at http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: [2.8]Slow connection causes problem
|
|
In reply to this post by Carl Gundel
Carl on our side we also use some javascript, but instead of changing the onClick action of the anchor/button we show the overlay div from the lightbox method over the screen after 1 second we update this to show a lightbox / modal dialog saying please wait and after a minute we add a message saying something appears to have gone wrong click here to refresh.
We do this in the following circumstances. 1. When a user clicks on an anchor or button. 2. A Prototype or jQuery request is made to the server. The overlay and lightbox are removed when the request returns.
3. When a page is loading. This prevents another issue that users can click on a submit button before the form tag has been closed which causes them to get redirected to the initial page. On 8 March 2011 05:06, Carl Gundel <[hidden email]> wrote: When I access my Seaside application using my iPhone over a 3G connection it is very easy to click on an anchor and then click on it or another anchor before I get a response. This often becomes a problem because the underlying state of my application is no longer valid for the second click. Clearly it makes sense for Seaside to handle this intelligently. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: [2.8]Slow connection causes problem
|
|
In reply to this post by Carl Gundel
Hi Carl,
How would you like Seaside to handle it? Is there a difference between this case and clicking on the link, waiting for the page to load, hitting the back button, and then clicking on a different link? Julian On Tue, Mar 8, 2011 at 3:06 AM, Carl Gundel <[hidden email]> wrote: > When I access my Seaside application using my iPhone over a 3G connection it is very easy to click on an anchor and then click on it or another anchor before I get a response. This often becomes a problem because the underlying state of my application is no longer valid for the second click. Clearly it makes sense for Seaside to handle this intelligently. > > -Carl Gundel > http://www.runbasic.com > http://www.libertybasic.com_______________________________________________ > 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: [Pharo-project] Seaside305 in Squeak 4.2
|
|
In reply to this post by Torsten Bergmann
> > Lukas wrote:
> > >I have a nicely working version of OB with RB, Shout and eCompletion > > >for Pharo 1.2. Just add <http://source.lukas-renggli.ch/pharo12 > > > > So you forked again and I wonder why? > > > > Because we don't have write access to Lukas' repository, and his changes > arrived on february. We where pushing OB changes in PharoTaskForces since > december. Yes, I read this on the list. The question was directed to Lukas, why did he fork again after your public accessible OB repository on squeaksource.com/PharoOB was created? All this is very confusing and I think it would be best if the public one is used now. But maybe Lukas has his reasons to maintain a private one for himself. Bye T. -- Schon gehört? GMX hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://www.gmx.net/de/go/toolbar _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: [2.8]Slow connection causes problem
|
|
In reply to this post by Julian Fitzell-2
Since Seaside claims to insulate the programmer from such things, it should have some mechanism to deal with this. I recognize that this is a difficult problem, but if it can be solved nicely in the Seaside framework that would be great. What happens is that if the connection is slow (or if my app responds too slowly, but this is not the case here) then it makes sense to be able to declare any action (or all the actions on a page or in an app, or for mobile browsers) as doable just once or maybe doable again after so many milliseconds or seconds. Then at least the developer can address the problem if needed. I supposed I could implement this myself somehow in my coding style. How would you recommend this best be done? Thanks, -Carl On Mar 9, 2011, at 3:12 AM, Julian Fitzell wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: [2.8]Slow connection causes problem
|
|
On Tue, Jul 5, 2011 at 4:19 AM, Carl Gundel <[hidden email]> wrote:
It's not so much that it's hard technically, it's that it's hard semantically. It's hard to even decide for one's *own* application what should happen when a user hits the back button (which, as I said, is more or less the same as clicking quickly on two links on the page). It near on impossible to make this decision in a way that's useful across applications. But as you say, the tools should be there to make it possible for application developers to make the decisions they want. We'd be open to suggestions on how you think such an API should behave. Probably the simplest existing approach would be to subclass WAActionPhaseContinuation and modify it so that it only allows itself to be invoked once. You can configure your application to use that subclass instead of the default. Beyond that, if you wanted finer control, you could look at having one-shot callbacks but I think that would be harder to implement at the moment and I'm not sure they'd be as easy to use with the standard canvas renderer. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |