[Tickets #11124] Re: decode_attribute hook an exceptions

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/11124
------------------------------------------------------------------------------
  Ticket             | 11124
  Updated By         | Jan Schneider <jan at horde.org>
  Summary            | decode_attribute hook an exceptions
  Queue              | Turba
  Version            | 3.0.12
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2012-04-03 22:42) wrote:

>
>> This is debatable, but I don't see a reason to artificially limit
>> which fields we allow to pass through the hook, just for code-flow
>> reasons.
>>
> A composite field is defined in terms of "turba-attributes"  
> (left-hand side of the map),
> this is different from directly  to "backend attributes" mapped  
> "turba-attributes".
> What is passed to the hook as the value of a composite field?
> I can't imagine a situation, where a composite field *and* a hook  
> for that field makes sense.
> I'd always use a direct mapping and do the other work in the hook.
> Isn't a composite field not some kind of simple inline hook?

I can imagine a field that requires different inputs from the user,  
i.e. different attributes, but the result should be rendered in a  
single composite field, after passed through the decode hook.

>> Well, maybe we could return an array in
>> Turba 4 instead, with a boolean as the first element, whether the hook
>> has been called.
> Is it possible to do it the old-fashioned way,  pass the value by  
> reference, and return a
> status code?

No, for that to work, the arguments need to passed by reference to  
Horde::callHook() too.