launchpad-dev team mailing list archive

[Guilherme Salgado <guilherme.salgado@xxxxxxxxxx>]

On 21/02/12 17:44, Benji York wrote:
> On Tue, Feb 21, 2012 at 2:12 PM, Guilherme Salgado
> <guilherme.salgado@xxxxxxxxxx> wrote:
>> And this means the parsing (which implies validating the input as well)
>> will happen twice: once when the form machinery validates the input and
>> again when it passes the raw input to updateWorkItems(). Since the
>> parsing involves looking up objects in the DB, doing this twice is not
>> ideal.
> 
> Perhaps you can cache the result of parsing in a location shared between
> the form validation and updateWorkItems() and use the string (or its ID)
> passed to updateWorkItems() to look up the parsed value (falling back to
> parsing from scratch if none is found).

That could work. Although this is arguably tying model code to the form
implementation, it shouldn't be a big deal if we have a fallback.  Now,
what shared location I should use for that?

> Another thought: if the form validators are allowed to return mutated
> values, you can return a subclass of str that has an attribute which
> stashes the parsed value.  updateWorkItems() can then check to see if
> the string it is passed has an already-parsed value along for the ride.

I'm not sure whether or not that's allowed but it looks I'd need to
change lazr.restful for this to work because it doesn't use the return
value of field.validate() when applying my mutator.

-- 
Guilherme Salgado <https://launchpad.net/~salgado>

Attachment: signature.asc
Description: OpenPGP digital signature