Yes, it is a forward link to the page, but as mentioned, that page
contains a form with the selection options, and on that form's action
page is where I don't see the values change, so the question should
probably be something like "how do I change the value in the session_var
with the newly selected value?
And oh, I almost forgot:
Due to that fact that this type of app doesn't really have a logical end
page, I cannot issue a session_destroy() anywhere logically ( except
using a logout button), but that's not going to ensure that people use it...
I would ideally like to have this "app" run on an intranet, where people
will most probably have this app open indefinately, and thus I also
battle with my logic of keeping a session alive.
Thanks
.
Rasmus Lerdorf wrote:
>Well, how exactly do you implement the back button? If it is a normal
>client-side back, then of course the previous value will be shown. If it
>is actually a forward-link to the previous page, then your logic on that
>target page is bogus.
>
>By the way, trans-sid is compiled in by default in PHP so should always be
>available. And it will fallback to sid mangling only if cookies are
>disabled. You would probably be better off just letting php manage this
>for you.
>
>-Rasmus
>
>On Tue, 30 Jul 2002, Petre wrote:
>
>>Well, I have asked a couple of questions on this list, but they havn't
>>really helped alot. Maybe you can help?
>>
>>My situation background is as follow:
>>I have always written my apps in the following way: register_globals=on,
>>so I allowed PHP to "generate" my variables for me on the action page,
>>and if I cannot use a form to "send" variables to the next pages, I
>>added them manually to the url.
>>So, then I discovered sessions and thought my probelms were solved, only
>>to discover that it uses cookies by default, and has to have the
>>--trans-sid option compiled to have PHP handle the app if you don't want
>>cookies ( like me, don't want cookies at all, or for that matter,
>>anything that relies on the client's side). So, I couldn't just jump in
>>and use sessions as I would not be sure that my app would work on any
>>PHP4 system regardless of the options it was compiled with. ( Oh, I am
>>writing my apps to work with register_globals=off now, so that shouldn't
>>be a problem).
>>So I started to look for a way to code with sessions that will not
>>require cookies nor require any special compile features; the answer
>>came in adding <?=SID?> to all relative URL's in my app.
>>Alas, that is where I'm at, and it's still not working as I would have
>>expected.
>>My problem is with the way my proposed app works/should work.
>>
>>I am trying to write an app that allows the user to log in, then
>>add/remove projects to his list, then, when a project is selected, he
>>should have access to all the relevan documents in that project, again
>>allowing him to add/remove documents from the project here, and in the
>>last step, when a document is selected, allows hime to add/remove/edit
>>chapters to the document.
>>
>>My first attempt at using sessions with this failed miserably ( keeping
>>in mind my approach of adding SID at end of urls). I have a "back" link
>>on all the pages that takes the user to the previous step(s) and thus
>>on the last page ( the chpaters edit/remove/add page), there is a link
>>to go back one level, two and three levels. Yet, using these causes
>>unexpected results.
>>I think the problem comes in with overriding the value of the session
>>variable.
>>For instance, on the first page you have a login form, on the action
>>page I session_register("username","password"), and that works fine even
>>when using the back buttons as the values are never changed. But, on the
>>2nd page I have the drop down select containing all the project names (
>>gets built with a while that reads all the project names from the
>>project_table) and send over the project_id.
>>On that actio page, I session_register("project_id"); and it also works
>>fine for all pages "down stream", however, when I come back to that page
>>to select a new project, it keeps the old variable...
>>At first I did nothing special in the sence of assigning a value to the
>>session variables, as I let the register_globals=on do it's trick, but
>>later I explicitly said
>>$project_id = $HTTP_POST_VARS["project_id"];
>>
>>But that also did not overwrite the value of the session var. In the end
>>I was forced to again add all my variables to the end of the url,
>>keeping the session solely for the username and password.
>>
>>I don't know if you would like me to post my code ( it is quite a bit
>>already ) but I would really appreciate it if someone could look at it,
>>and then point out where I'm missing the picture, as then I would have
>>two pictures that I can compare and see where my reasoning failed.
>>
>>Thanks for your time.
>>
>>
>>Rasmus Lerdorf wrote:
>>
>>>What issues? Just ask.
>>>
>>>-Rasmus
>>>
>>>On Mon, 29 Jul 2002, Petre wrote:
>>>
>>>>What are good books/websites about sessions.
>>>>I'm looking for more advanced stuff, I have the Luke Welling/Laura
>>>>Tompson book, and have read the manual, but I still have issues that are
>>>>unresolved.
>>>>
>>>>Thanks
>>>>
>>>>
>>>>
>>>>--
>>>>PHP General Mailing List (http://www.php.net/)
>>>>To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
