Let's return to this subject, which was discussed a couple of weeks
ago. Here's my latest thinking on the subject.
* Automatic manipulators go away. Instead of messing with those, to
create a new model object you try instantiating it. Validation errors
are raised at that point. Example:
try:
Am 22.02.2006 um 08:12 schrieb Adrian Holovaty:
> Let's return to this subject, which was discussed a couple of weeks
> ago. Here's my latest thinking on the subject.
>
> * Automatic manipulators go away. Instead of messing with those, to
> create a new model object you try instantiating it. Valid
Adrian Holovaty wrote:
>* Specifically, validation happens on Model.__init__() and
>Model.__setattr(),
>
Ouch... Last time this was discussed this was considered bad thing (I
may be mistaken) because this doesn't allow any intermediate non-valid
state for an object which nonetheless may be usef
On Wednesday 22 February 2006 04:13, Christopher Lenz wrote:
[snip]
>
> Why not do the validation on Model.save(). The developer can not
> "forget to validate", but the model instance is allowed to be invalid
> temporarily, until it is fully populated and actually gets saved.
I agree. It's a lot
On 2/22/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
Let's return to this subject, which was discussed a couple of weeksago. Here's my latest thinking on the subject.* Automatic manipulators go away. Instead of messing with those, tocreate a new model object you try instantiating it. Validation e
>* This plan is nice conceptually because it doesn't leave any chance
>of bad data in any model instance. Currently, Django is "dumb" about
>data in model instances -- it allows any arbitrary data there, and
>catching bad data is completely the responsibility of the developer.
>This can lead to so
I like the idea. Perhaps you could have a class method
without_validation() for the bulk upload?
Maniac wrote:
> Adrian Holovaty wrote:
>
> >* Specifically, validation happens on Model.__init__() and
> >Model.__setattr(),
> >
> Ouch... Last time this was discussed this was considered bad thing (
Maniac wrote:
>The concept of always keeping object in a correct state is indeed very
>nice but makes some practicle cases really harder.
>
>
I want to share an experience working with Delphi's VCL (library of
visual components) where this thing was solved in a very convinient way.
The inte
kmh wrote:
>> This breaks semantics of a property of an object: you should be able to
>> read exactly what you just set. Imagine explaining this magic to a newbie:
>>
>> c.crime_date = request.POST['crime_date'] ## user submits '2006-1-2'
>> if c.crime_date == '2006-1-2': ## false!
>>
kmh wrote:
>Or we could have an update() method that took multiple arguments like
>the constructor.If two fields do depend on each other for validity
>then it makes sense that you can't set them separately.
>
>
This makes sense. However setting several fields at once is only one of
the pro
Maniac wrote:
> I think it shouldn't be magical here because user shouldn't use this
> often at all. I think automatisation of converting a form to an object
> should happen a level higher like this:
>
> c = Crime.parse_form_data(request.POST)
>
> parse_form_data would iterate over field objec
Hey Adrian --
In general, I think this is a pretty good idea. However, I've got
quite a bit of code the does something similar to the following:
obj = SomeObject()
for field in some_dict:
setattr(obj, field, some_dict[field])
obj.save()
i.e. build up o
On 2/22/06, kmh <[EMAIL PROTECTED]> wrote:
I like the idea. Perhaps you could have a class methodwithout_validation() for the bulk upload?I do not get the point of this whole discussion, if you are doing form handing your views, manipulators are good because they are consistent with the custom for
On 2/22/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Let's return to this subject, which was discussed a couple of weeks
> ago. Here's my latest thinking on the subject.
>
> * Automatic manipulators go away. Instead of messing with those, to
> create a new model object you try instantiating
On 2/22/06, Maniac <[EMAIL PROTECTED]> wrote:
> The concept of always keeping object in a correct state is indeed very
> nice but makes some practicle cases really harder. So I would vote for
> late validation on save() or explicit validate().
+1 on the idea in general.
I like validate(). I thi
On 2/22/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
prep_data would take the request, and return a dict suitable to passto the objects constructor. FWIW I think prep_data is a bad namethough. Other suggestions?Maybe something like this:new_data = MyModel.prep_data
(request)my_obj = MyModel(new
> * As a side effect, generic create/update views will not be able to
> use edit_inline stuff; that will only be an admin feature. I am 100%
> fine with that, as I have never seen a need for using edit_inline out
> of the admin -- it is an admin-specific phenomenon. We could indeed
> expose the lo
On 2006-02-22, at 11:18 CET, hugo wrote:
> I would propose to instead do validation in those situations where the
> data is moved to the external storage - on .save() (or in the
> unit-of-works .save() if we have them). That way you can happily
> create
> invalid objects, but you will be forced
Am 23.02.2006 um 11:04 schrieb Robert Wittams:
> * The hack fields like auto_now and auto_now_add will need a
> rethink. I
> really don't have much of an idea what you can do to make these
> sensible. Some callback on .save() maybe.
I've been wondering about this one... SQLObject allows you to
"""c.crime_date = datetime.date(2006, 1, 2)
c.crime_date = '2006-1-2'
In the second example, c.crime_date would immediately be converted to
a datetime.date object. What are the pitfalls to this approach? """
Providing this type of "Magic" is a bad idea because it's not explicit
in f
Nebojša Đorđević wrote:
> On 2006-02-22, at 11:18 CET, hugo wrote:
>
>> I would propose to instead do validation in those situations where the
>> data is moved to the external storage - on .save() (or in the
>> unit-of-works .save() if we have them). That way you can happily
>> create
>> invali
I'm not sure that this is 100% relevant to this discussion, but wanted
to share it in the context of this thread.
A Python type checking module:
http://www.ilowe.net/software/typecheck/
--Nick
--~--~-~--~~~---~--~~
You received this message be
22 matches
Mail list logo
