[dev] [cvs] commit: whups/lib api.php
Jan Schneider
jan at horde.org
Mon Aug 15 09:16:57 PDT 2005
Zitat von "Jason M. Felice" <jfelice at cronosys.com>:
> Quoting Thomas Gelf <horde at gelf.net>:
>
>> Am Mittwoch, den 10.08.2005, 10:57 -0700 schrieb Jason Felice:
>>> * If the user has a custom ticket attribute "Estimated Time", use
>>> it to return hour estimates for ticket-based cost objects.
>>
>> Hmmm... I don't really like the way how this was done:
>>
>> * attribute key is being compared with _("estimated time") which has not
>> been translated (yet), but once it will be and then we'll run into
>> trouble - at least people used to change language settings very often
>> (like me :)
>> What about using at least a constant value? And as Jan has written
>> before this should be documented somewhere - and some note how to
>> correctly add a "custom ticket attribute" would also be nice.
>
> Here's my thoughts:
>
> * The attribute key is being displayed currently, so my thinking was
> that it needs to be translated.
That was a good assumption.
> * Perhaps the "right" way to do this is to have another value that is an
> untranslated value which is not normally displayed. Then we could make this
> "estimate_hours". Question: what to call it? Should we rename "Attribute
> Name" to "Attribute Display Name"?
That's a good idea, and we discussed this briefly in IRC, while you was
away. It would make sense to extend the attributes to have a name, a
display name, a form field type, and parameters for the form field.
This way people could define very flexible attributes.
> * As a sidenote, when I looked at it, I thought it might be cleaner to
> have the
> driver return addtional attributes in getTicketDetails(). If we used this
> as the key name, this should work (we just have to prevent the user from
> naming attributes after reserved fields).
I would consider this overhead, unless we need the attributes together
with the ticket information in many places.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
More information about the dev
mailing list