(so I finally understood Ajax?
B-)
)

2012/3/4 Fibo <[email protected]>

> 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?
>
>
>
>
> Le samedi 3 mars 2012 02:14:50 UTC+1, Remi Grumeau a écrit :
>
>> 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
>>
>> On 2 mars 2012, at 16:41, Fibo <[email protected]> wrote:
>>
>> 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.
>>
>>
>>
>> Le jeudi 1 mars 2012 09:42:33 UTC+1, Remi Grumeau a écrit :
>>
>>> > 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<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
>>>
>>>  --
>> 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<https://groups.google.com/d/msg/iphonewebdev/-/fqGDe5uxrjUJ>
>> .
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to iphonewebdev+unsubscribe@**
>> googlegroups.com <[email protected]>.
>> For more options, visit this group at http://groups.google.com/**
>> group/iphonewebdev?hl=en<http://groups.google.com/group/iphonewebdev?hl=en>
>> .
>>
>>  --
> 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/-/k9rEufzxpv4J.
>
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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*

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

Reply via email to