Re[2]: [phplib] Problem with newly commited user4.inc From: Max A. Derkachev (kot <email protected>)
Date: 01/09/01

Hello Marko,

Friday, January 05, 2001, 8:59:20 PM, you wrote:

MK> finally I found my error!
MK> Up to now I successfully coded as follows:
+ $user->register('LFC'); if(!isset($LFC)) $LFC=new LFilterClass;

It's logically wrong with User3. It's completely wrong with User4
:) You should first instantiate an object, and then register it,
shouldn't you?
if (!isset($LFC)) {
$LFC = new LFilterClass;
$user->register('LFC');
}

MK> i.e. without applying $user->is_registered() before.
MK> And the second error is also immediately clear: I do the new after the
MK> registration... Bad idea...
MK> This way it works fine:
MK> + if(!isset($EFC)) $EFC=new EFilterClass;
+ if(!$user->is_registered('EFC')) $user->register('EFC');

I guess both isset() and $user->is_registered() should work,
if $register_globals in the new User class is set to true ...
Check if the $EFC is in the global namespace after the page_open() call.
It should be there.

MK> BUT: This shows that there is another potential problem for porting
MK> phplib3 style scripts to phplib4! Don't you think so? Well, I am happy
MK> that I got this finally working. ;) THanks very much for your immediate
MK> help.

The class is compatible if the $user->register_globals is true.

MK> You know, I think this is stable enough to work in my production
MK> environment already. Great!!!

Good to hear it :)

MK> By the way: I understood your argument concerning the possibility to use
MK> the old tables. Of course, their structure didn't change after all. It's
MK> only the coding of the val. I only mentioned that the old style of saving
MK> that as a real script allows to switched without problems between
MK> different phplib versions. But okay, it looks like this is not necessary
MK> anyway, because your port seems to be working fine so far, even for
MK> the user class, eventually!!!!! ;)

The old format was plain php code that should be feed to eval() to be
deserialized. The new format is the format of the serialize() function
(by default) and decoded by php's internal C routine.
The second way is a lot faster, I suppose 2 or more times, then the first,
while deserializing.
At the other side, a huge loop with recursion in php is used to
'serialize' variables. The new way uses another built in php C routine.
I guess those two builtin routines make not less than 90% of the speed increase of
PHP4 native sessions compared to PHPLib 7.2 Session.
Don't think we should leave the format of the data compatible with the
old PHPlib. It does not make sense. The data, of course, could be
converted to the new format.

MK> Well, Max, I am still not quite clear in my head concerning this mixing of
MK> session and user class... I understood that there is a certain
MK> interference in PHP4 between session and user, but does it actually mean
MK> that still these classes shouldn't already be used together. At first
MK> glance I still can't see any problems. The user class saves all user
MK> variables properly and session is totally independent from that.

The old phplib's Session and User class use the same common serialize and
deserialize routines. The new Session uses session_encode() to serialize
and session_start() to recreate the variables.
That is not acceptable with the User class - it should have its own routines
and data structures, not session's. It has now. 

-- 
Best regards,
Max A. Derkachev mailto:kot <email protected>
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
http://www.Books.Ru -- All Books of Russia
 

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>