[Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net

[Maxim D. <max...@bo...>]

Hello Joe,

Wednesday, September 25, 2002, 8:33:33 PM, you wrote:
>>  This could be also done in prepend.php by doing extract($_SESSION);
 
JS> Yes. This would put more conditionals in prepend which I personally don't 
JS> like.

Sorry, I meant page.inc, not prepend.php, which is used to include all
the necessary classes. Page.inc itself just for such conditionals.

JS> It also moves code that is required for session4.inc to work 
JS> correctly in this state out of the class.
Well ... but that would be much more efficient :)


>> in Ssssion::is_registered:
>>  return session_is_registered($var_name);
>>  should be
>>  return (session_is_registered($var_name) || 
>>  isset($_SESSION[$var_name]));
 
>>  in Session::unregister:
>>  $ok = $ok && session_unregister ( trim($var_name) );
>>  should be
>>  $var_name = trim($var_name);
>>  $ok = $ok && (session_unregister($var_name) || 
>>  unset($_SESSION[$var_name]));
 
JS> What effect should you see with this change?

Variables may be registered in both ways, by using $sess->register()
or by direct assignment to $_SESSION keys. So, we should mind both
ways in is_registered and unregister. I suspect
session_register/session_unregister/session_is_registered know nothing
about $_SESSION array. $_SESSION and $HTTP_SESSION_VARS (the old way)
are different arrays, and not linked to each other.

JS> I ask because Gian's patch basically chose the _SESSION route if globals 
JS> off.  He and I found that the session_register, session_unregister, and 
JS> is_registered all function as before.  See his added note to the patch on 
JS> sf.net.
JS> The one anomaly he found is on the same iteration that the session
JS> variable is registered, he could use $_SESSION[variablename] to get the 
JS> variable contents.  I have not been able to get this to work ( It could be 
JS> my test).  

Yes, I saw the note, but if they changed the behavior once, nothing
prevents them from changing things again, e.g. for performance
reasons. The documented behavior is that those functions don't work
with register_globals=off.



>>  maybe references to the session variables should be put into $_SESSION
>>  in Session::register as well, since $HTTP_SESSION_VARS and $_SESSION
>>  are not the same arrays. That would eliminate freeze in Session. I
>>  don't like that freeze idea :)
 
JS> In practice this hasn't worked for me.  I'd like to get rid of that ugly 
code in sess->>freeze too.  It was just proof-of-concept.

If we register variables the both ways in the both session arrays,
freeze hs nothing to do in Session4, cause the standard savehandler
itself knows where to look for the session variables (though, it needs to be in
Session4_Custom)




-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru