Jacob Kaplan-Moss wrote:
> On Mar 13, 2006, at 9:41 PM, James Bennett wrote:
>> Sure they can. Imagine explaining Django to someone who's never seen
>> an MVC model before; if you told them "the model is where you provide
>> all the information about a class of objects, and describe how it
>> works", they'd be awfully confused if you then said, "oh, except for
>> this and this and this, which have to be specified somewhere else."
>>
>> Better to have all the information about a class of objects, including
>> whatever information is needed to validate it, all in one place.
>
> That's a great explanation, James.
>
> To explore it a bit further: I'm often asked why Django doesn't use
> SQLObject or some other Pythonic ORM. My standard answer is that
> Django's ORM does a lot more than just describe how to map relational
> tables to Python objects: it explains how to construct an interface
> for editing the object, it describes validation information about an
> object's fields that the database often can't encode, and so on.
>
> Given that, I think validation is something that very much SHOULD be
> defined and happen on the model. Yes, this runs counter to MVC, but
> we've already established that Django isn't exactly MVC anyway. As
> I see it:
>
> - Model: describe the data
> - View: describe what the user sees
> - Template: describe how the user sees it
>
i'm fine with this approach, i have no problems with the model
validating itself.
my problem is with the model auto-converting data to a suitable format.
i think it should be an explicit thing, not an implicit one.
it's ok if the model checks if the DateField is a datetime.date (or
whatever) object. but i don't like it that it will not fail when there's
a string, and it will convert it to a datetime.date object.
to specify it better:
- in my opinion, validation should not convert date. it should validate.
- data conversion should be a separate task.
please, could you describe some situations, where it's so good to be
able to play the everything-is-a-string game?
i see, that with this auto-convert approach, you will be able to do
something like:
def myview(request):
try:
m = MyModel(**request.POSTDATA)
m.save()
except SomethingFailedError:
//handle it
or something like that.
but for me it feels more pythonic to do it like:
def myview(request):
try:
m = MyModel( MyModel.hmtml2python(**request.POSTDATA))
m.save()
except SomethingFailedError:
//handle it
or have a new constructor, that takes a dictionary of strings:
def myview(request):
try:
m = MyModel( request.POSTDATA)
m.save()
except SomethingFailedError:
//handle it
anyway,
1. if there are other use-cases where it makes sense to have everything
in strings, please tell me.
2. it's a matter of how much pythonic you want your objects to be.
python does not auto-convert an int to a string when needed, so if
models will do so, they will be slightly less pythonic. i'm not saying
you should not do it, i'm only saying it will be less pythonic.
3. even if this auto-converting approach will become the way to do it in
Django, i will still use Django for all my web-app needs :-)
gabor
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
