Re: Client storing query state (was Re: Adding and removing images to/from gift)

>> yes, that's true but it doesn't help much. It is only of value as long
>> as the user is seeing
>> the thumbnails which are displayed by the mrml output client script.
>> Try to imagine the users click path:
>>
>> - search images ( query )
>> - get search results ( page with gift results as thumbnails )
>> -- now the users wants to see the article and clicks on the thumbnails
>> which
>>    will redirect him to the article page
>> -- now the users want's to go back to the search results because this
>> article
>>    was not what he was looking for.
>>
>> the last step will always fail if you deploy the system with hidden
>> input fields, because
>> the former page used to be a posted one so the browser will not go
>> back. The only way to
>> solve this problem is to store what the user selected before - either
>> in gift itself ( which
>> is deprecated ) or somewhere inbetween.
>>     
>
> So you can do what my client does. It establishes a unique interface
> session ID and stores the required state on the machine where the
> interface is running, passing the interface session ID as a hidden
> field. I do this in a quick and dirty file in /tmp, but you could make
> it as nice as you like on the (interface) server, using proper
> server-side sessions, etc.
>   
Hi David,

is it possible to use my already existent php session id's when 
initiating the query or do I have
to use the session id's offered and link them to the users php session 
id. Both cases would
eliminate the need to supply hidden post / get data but using the 
already existing php session
id's would be much more elegant I think.