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

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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.

But we don't store whatever the heck we want, we store a standardized  
data format. Just broken.

>>> // 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).

The approach is wrong. If we use a standard format to store stuff,  
then we must stick to that standard and don't break it. Everything  
worked fine that way in Horde 2 too. Until a situation popped up that  
we didn't think of that broke everything, so we had to re-do it for  
Horde 3. You simply don't know how we are going to access that data in  
future, and there might be folks that access this data directly. I  
know, this is not supported, but people will do it. I know, they can  
convert the data themselves, but they will forget, because in 95% of  
cases it works without.
If we use a portable storage format, then keep it portable. I  
understand that this will work perfectly as long as you use the  
(current) Prefs API. But this is like storing all our calendar data in  
iCalendar files, but then decide to use unix line breaks instead of  
CRLF, because it still works fine in our calendar app, and because  
it's installed on Linux systems 99% of the time any way. It's still  
wrong.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/