Dumping the stack and the back button

[Fibo]

After some form validation, I want to return to the main page of the
app with no "backbutton" in the toolbar. This is probably written in
the doc... but I can't find it and my trial and errors just fail to
get this working.
Any idea or suggestion?

[Remi Grumeau]

Hi Bernard,

As a quick answer, I would suggest:

history.go(-(history.length-1))

but it probably needs some more testing...

Remi

--
You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group.
To post to this group, send email to iphone...@googlegroups.com.
To unsubscribe from this group, send email to iphonewebdev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.

[Paul Libbrecht]

Bernard,

isn't that a sin for a web-page?
Or are you talking of an app that is not a web0browser?
I think your desire should not be doable.

To avoid that a back repopulates all the data of a previous workflow
you should simply set the appropriate expiration in the headers.

paul

[Fibo]

Paul,

Going back/ jumping back to your home page is something needed
frequently, so I don't think its qualifies as a sin B-)

In my case, user makes a car reservation thru several successive
screens. When the reservation is completed, I want to jump back
directly to my homepage, not to force the user to "backbutton" several
times: THAT would not be very user-friendly, right?

[Fibo]

On 29 fév, 20:38, Paul Libbrecht <p...@curriki.org> wrote:
> Bernard,

> ...

> To avoid that a back repopulates all the data of a previous workflow
> you should simply set the appropriate expiration in the headers.
>

This seems an elegant solution. How could I implement it simply, so
that (php-generated) html code updates when needed?

I am taking a functionally similar route... But slightly bruteforce:
defining an onevent monitoring a screen-focus which would do some
cleanup by javascript.

[remi_grumeau]

On Feb 29, 11:50 pm, Fibo <bernard.savo...@gmail.com> wrote:
> Paul,
>
> Going back/ jumping back to your home page is something needed
> frequently, so I don't think its qualifies as a sin B-)

Agree, this should come built-in in iUI (blame the core team :) )

> In my case, user makes a car reservation thru several successive
> screens. When the reservation is completed, I want to jump back
> directly to my homepage, not to force the user to "backbutton" several
> times: THAT would not be very user-friendly, right?

Clearly not.
Please consider what i did sent you.
See live example:
http://we-are-gurus.com/labs/iui/sandbox/back-home/index.html

Remi

[Paul Libbrecht]

Le 29 févr. 2012 à 23:50, Fibo a écrit :
> In my case, user makes a car reservation thru several successive
> screens. When the reservation is completed, I want to jump back
> directly to my homepage, not to force the user to "backbutton" several
> times: THAT would not be very user-friendly, right?

Oh sure, so you just need to redirect (in JS or in headers) after form submission???
(e.g. window.location.href='http://mysite.net/index.html" ??)
People do this commonly to receive the form (especially the final form) as a post but then redirect to a page that is obtained in get).
Your original message talked about removing the back button... therefore it was a sin.

paul

[Remi Grumeau]

> Le 29 févr. 2012 à 23:50, Fibo a écrit :
>> In my case, user makes a car reservation thru several successive
>> screens. When the reservation is completed, I want to jump back
>> directly to my homepage, not to force the user to "backbutton" several
>> times: THAT would not be very user-friendly, right?
>
> Oh sure, so you just need to redirect (in JS or in headers) after form submission???
> (e.g. window.location.href='http://mysite.net/index.html" ??)

Then what if user press browser back button ?

> People do this commonly to receive the form (especially the final form) as a post but then redirect to a page that is obtained in get).

You can do HTTPRequest using POST method rather than get using:

var xhReq = createXMLHttpRequest(); // this is a function to return the XHR object based on browser detection
var params = "var1="+input1.value+"&var2="+input2.value;
xhReq.open("post", "/submit?d="+(new Date().getTime()), true);
xhReq.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xhReq.onreadystatechange = function()
{
if(xhReq.readyState == 4 && xhReq.status == 200)
{
// xhReq.responseText is the value your script returns.
history.go(-(history.length-1));
}
}
xhReq.send(params);

No need to reload the page to send a POST form.

I know there is something built-in in iUI for form but i just don't really know how it works :)

Remi

> Your original message talked about removing the back button... therefore it was a sin.
>
> paul
>
>
>>
>>
>> On 29 fév, 20:38, Paul Libbrecht <p...@curriki.org> wrote:
>>> Bernard,
>>>
>>> isn't that a sin for a web-page?
>>> Or are you talking of an app that is not a web0browser?
>>> I think your desire should not be doable.
>>>
>>> To avoid that a back repopulates all the data of a previous workflow
>>> you should simply set the appropriate expiration in the headers.
>>>
>>> paul
>>>
>>> On 22 fév, 14:37, Fibo <bernard.savo...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> After some form validation, I want to return to the main page of the
>>>> app with no "backbutton" in the toolbar. This is probably written in
>>>> the doc... but I can't find it and my trial and errors just fail to
>>>> get this working.
>>>> Any idea or suggestion?
>

[Fibo]

This works fine. In my case it was length-3, but this is because my "home" page is in fact one level after the real home page: user is asked there to login, afterwards his/her top page remains at the "login sucessful" level<.

 

Le mercredi 22 février 2012 16:04:08 UTC+1, Remi Grumeau a écrit :

Hi Bernard,

As a quick answer, I would suggest:

history.go(-(history.length-1))

but it probably needs some more testing...

Remi

On Wed, Feb 22, 2012 at 2:37 PM, Fibo <bernard...@gmail.com> wrote:

After some form validation, I want to return to the main page of the
app with no "backbutton" in the toolbar. This is probably written in
the doc... but I can't find it and my trial and errors just fail to
get this working.
Any idea or suggestion?

--
You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group.
To post to this group, send email to iphone...@googlegroups.com.

To unsubscribe from this group, send email to iphonewebdev+unsubscribe@googlegroups.com.

[Fibo]

Thx Remi and Paul for your answers!

 

I was trying to escape calling again the form (or the nice equivalent Remi gives).

Seems this will be the most elegant situation, I will need however to re-log the user, hence keeping its password probably in a cookie, with some sort of md5 to give some elementary protection.

[Remi Grumeau ]

oh oh... for a login/password access to a website (other than .htpassword-like solution), you'd better reload the page between the login screen & home screen.

first, when reloading the page, you reload all headers, including sessions. So then, you can use session vars instead of trying to use some cookie based workaround or whatever....

Remi Grumeau

--

You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/iphonewebdev/-/fqGDe5uxrjUJ.

[Fibo]

Just to be sure:

- my php scripts generate on the server content which is then ajaxed into the client's page

- the client's page uses this html as well as javascript from libraries (out of which iUI and its add-ons) and from outside pages (eg, php-generated code executed thx to jit-loader)

 

- so somehow the php scripts on the server and the html/javascript on the client have parallel life

- the only way php can "read" javascript values is thru the form fields and the cookies fields

- php can "communicate" static values to javascript, when in fact it generateson the server the javascript code that will be later evaluated on the client

- php can access persistent values thru session variables and cookies variables.

 

As far as I understand, there is no direct way for javascript running on the client to read session data which in fact live on the server (eg, http://www.experts-exchange.com/Q_20187093.html )

 

So you suggest that I keep the login info (and others) in the session on the server, where my php scripts will indeed be able to read/ write them, even though the client code ignores these values.

 

This is something I had not realised, and which opens me new solutions to the problems I met, where I was trying to do everything in (sometimes php-generated) javascript on the client.

Can you confirm this is what you had in mind?

To unsubscribe from this group, send email to iphonewebdev+unsubscribe@googlegroups.com.

[Bernard Savonet]

(so I finally understood Ajax?

B-)

)

2012/3/4 Fibo <bernard...@gmail.com>

To view this discussion on the web visit https://groups.google.com/d/msg/iphonewebdev/-/k9rEufzxpv4J.

To post to this group, send email to iphone...@googlegroups.com.

To unsubscribe from this group, send email to iphonewebdev...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.

--

--------------------------

Votre espace "cloud personnel" avec DropBox: cliquez http://db.tt/9Unx0Kg

 

[Remi Grumeau]

Yes.

Server side sessions (aka $_SESSION) only lives on the PHP side, before the DON generates.

My point with sessions & login is that when you login someone, you usually puts a few dataset in sessions (username, md5 of password, user Id, token...) but you must remember that session is generated on document load since it lives in the document's header.

So if you load page 1 which is a login form that ask page2 tru xhr to check ident / password, it's OK. If page 2 puts stuffs in sessions, you'll have to refresh page 1 to access them from page 1.

But if you really need to read datas  from the server via PHP, just create an Ajax call to a PHP script and populate some variables with it (JSON might help). Also, remember that all smartphones web browser's iUI is compatible with supports localstorage. Those are way better than cookies...

Sent from my BlackBerry® PlayBook™
www.blackberry.com

---

From: "Bernard Savonet" <bernard...@gmail.com>
To: "iphone...@googlegroups.com" <iphone...@googlegroups.com>
Sent: March 5, 2012 1:30 AM
Subject: Re: Dumping the stack and the back button