[dev] [commits] Horde branch master updated. 76152d6a2976549c96ae0aec5b20c4669b8a68bf

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> // $a stored in backend
>>
>> // ...
>
> In the backend should be stored a valid serialized string, but it isn't:

Why does it need to be a valid PHP serialized string?  It doesn't.  We  
can store whatever the heck we want in the backend.  As long as the  
driver knows the string translation used, it doesn't matter.

>> // Retrieve in backend.
>> $b = $a;
>
> unserialize($b);
>
> PHP Notice:  unserialize(): Error at offset x of y bytes

Why are you doing this?  Of course this isn't going to work - the  
value in the backend is not valid PHP serialized data.  But this will  
NEVER happen.  Nobody should EVER be directly manipulating data from  
the backend - to retrieve data you MUST use getValue().  And by the  
time the user gets the preference value from a Horde_Prefs::getValue()  
call, the string has already been charset converted (if necessary).

In other words:

$prefs->setValue('pref', $foo);
..
$bar = $prefs->getValue('pref');

// RESULT: $prefs === $bar;

This is all the end user cares about: Is the return from getValue()  
the same as the original value they stored?  The answer is yes (or at  
least it has yet to be proven otherwise with the new code).

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]