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
What is Jinja?
Jinja is a text-based template language similar to cheetah and Smarty.
The syntax and parts of the code where taken from the django template.
http://wsgiarea.pocoo.org/jinja/
--~--~-~--~~~---~--~~
You received this message because you are subscribe
Would it be worthwhile for the people with a thorough understanding of
what's going on under the hood to create a tickets in Trac for the work
remaining to finalize m-r? Then you could ostensibly set a target date
for the completion of the milestone. That would give everyone something
to strive fo
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, 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, 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
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
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
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
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!
>>
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
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 (
>* 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
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
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
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
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
> I, for one, want to get m-r wrapped up and merged back to trunk as
> soon as humanely possible. I feel like it's starting to be a drag on
> new users trying to figure out why development on trunk seems to have
> stopped, and I want to get us all back to one codebase.
+1
Arthur
--~--~
18 matches
Mail list logo
