Tickets :: Comment on [#11124] decode_attribute hook an exceptions

Search Results: 39 of 57 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: . ..__ . .. ..__. \|__\|[__)\|\/\|\|\ \|[__] \| \|[__)\| \|\| \\|\| \|
Comment	>> >>> 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.
Attachment
Watch this ticket