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

[Philip Kime]

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

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
> 

--