[Rt-devel] RE: [PATCH]: Data normalisation for multi-valued CFs in GUI create

[Jesse Vincent]

On Wed, Feb 21, 2007 at 11:22:07PM -0800, Philip Kime wrote:
> I consider it a bugfix really. I want to be able, after calling
> ->SingleValue on a CF to know that I have a piece of text or an array
> ref to deal with. If I have to data type check in addition after this,
> because the nice OO call doesn't encapsulate the data type, it makes the
> nice ->SingleValue interface less useful and the code more confusing. It
> behaves nicely for EnterMultipleValue fields, just not
> SelectMultipleValue for some reason. I'd like to do it at this point
> because this is the point where this discrepancy is introduced. I'm not
> doing any error checking or manipulation at this point, but I am later
> on and that's when you find out that the datatype for
> SelectMultipleValue CFs isn't consistent and needs checking for data
> type again. SelectMultipleValue CFs created via REST for example, don't
> need this extra check as they are are always array refs, nomatter how
> many values, so at the very least, there is a discrepancy between the
> GUI and REST (and CommandByMail, as it happens).
>

From your patch, it looks like all you're doing is changing how
RT::Interface::Web::CreateTicket calls RT::Ticket->Create();

RT::Ticket->Create() is designed to accept any custom field value as
either a single value or an array ref, no?  Even for a Single valued
custom field.  The value is automatically coerced into an arrayref on
the fly.

Changing how R:I:W:CreateTicket calls Ticket->Create doesn't seem to
me to win you anything and if you're writing code in Ticket->Create()
that expects only one or the other, then you're doing it in the wrong
place. 

Jesse


> PK
> 
> -----Original Message-----
> From: Jesse Vincent [mailto:jesse at bestpractical.com] 
> Sent: Wednesday, February 21, 2007 7:53 PM
> To: Philip Kime
> Cc: rt-devel at lists.bestpractical.com
> Subject: Re: [Rt-devel] RE: [PATCH]: Data normalisation for multi-valued
> CFs in GUI create
> 
> 
> 
> 
> On Wed, Feb 21, 2007 at 07:49:01PM -0800, Philip Kime wrote:
> > 
> > > That sounds like it's going to be an API change that's backwards 
> > > incompatible. Why can't you just do canonicalization once it's in 
> > > sub Create?
> > 
> > I think there maybe some misunderstanding - this isn't an API patch - 
> > it's a patch to the GUI-only CreateTicket() sub in Web.pm, not the API
> > Ticket::Create() sub. CreateTicket is a wrapper which massages MASONy 
> > things into the right shape for a call to Ticket::Create() later. I've
> 
> > just altered the massaging a little. Ticket::Create() copes fine with 
> > arrays of one value as values for multi-CFs.
> 
> I did misunderstand. However, given that, what's the point of the
> change? You really don't want to be doing any sort of error checking or
> data manipulation at that level.
> 
> > 
> > PK
> > _______________________________________________
> > List info: 
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
> > 
> 
> -- 
> 

--