I'm not sure it makes sense to put something that raises a "BadRequest" type error in the model. That's more of an API exception. I'd say put it in the resource. If you find yourself repeating it a lot then put the validation in it's own function and/or use subclasses if appropriate.
_Nik
On 2/9/2014 10:18 AM, Arnold Krille wrote:
> On Sun, 9 Feb 2014 02:15:46 -0800 (PST) Glyn Jackson
> <me@glynjackson.org> wrote:
>> So far I have moved this logic around so many times, but where should
>> it really be happening in my Django project? Opinions very much
>> welcome. Thanks
>>
>> 1) product *pre_save* - this works really well but validation looks
>> odd here!
>> 2) product *model save()* - again validation looks odd here!
>> 3) product *model manager *- this seems bad as I'm referencing the
>> stock model in product manager.
>> 4) *views* - I end up repeating the save validation and code looks
>> really bad, also I have to do it again for API and normal views
>> 5) *tastypie recourse* - just as bad as views I think.
>
> Model! If its validation and 'save' should stop if there is none in
> stock, its either a pre-save-trigger or on your own save-method before
> calling super(...).save(). Be aware that if you subclass your product,
> a pre-save trigger has to get connected to all derived classes too, so
> it might be easier to just add it to the save-method.
>
> The advantage is clearly that the same code is used for all views. And
> api-resources are a view too (or a controller but lets not discuss
> thie here).
>
> - Arnold
No comments:
Post a Comment