Serialization of single object instead of only querysets.
Please visit the following URL, and when you do, put your focus into the search form after "seri" and type the letter "a". You'll notice the top search for anything related to Django serialization is "Single Object". This is because people want to have this feature. Serializing a single object can be accomplished right now but you have to make pass it in a list like this: [my_object]. This isn't a huge problem. The problem comes when you're writing your outside code (JavaScript, et all) against the API you've now built. You need something like user[0].first_name instead of just user.first_name. It's not a huge coding difference. It just seems broken and confusing, especially to newcomers. Here's the URL: http://www.google.com/#hl=en&q=django+seri&aq=f&aqi=g10&oq=django+seri -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Serialization of single object instead of only querysets.
Thank you Karen. I've been hushed so many times about this, yet there seems to be a growing concern (hence the search traffic, and number of results) about why you can't naturally do this with Django's built-in serializer. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: examples directory
-1 I think examples, broken or working, are very helpful for absolute beginners. Maybe there should be strict warnings about the quality of the code (in a similar fashion to the ones that warn you when you view old docs). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Serialization of single object instead of only querysets.
Addendum: I might be simply abusing `serialize`. I'm using it as a Django compatible `json.dumps` in order to provide a JSON API from my models to my JSON-RPC client. There seems to be no more extensible way. If this isn't one of the intended uses, let me know and I'll leave it alone. Again I apologize for any apparent allusion of hostility towards Django or the developers. I'm your #1 fan (ran here as fast as I could from RoR a year ago). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Serialization of single object instead of only querysets.
@Everyone I apologize if I came across as using hyperbole or idiotic. I never said I was hushed here, not even one time. I was hushed on code.django and sent here. Yes hushed might be a bit of an exaggeration, somebody basically closed my ticket and says go get consensus before reopening a ticket, without addressing any of my concerns him/herself (ie, "Even though you bring up a popular point according to search volume, please leave"). The other place was StackOverflow where I basically got the same "Here just do this snippet. It's not worth changing the code for such a simple task" sort of reply, which is helpful indeed but not why I'm raising the point. My "growing concern" statement is based on the fact that Google placed it at the top for any Django serialization related searches. This is not me being assumptive. This is a fact that it is the single most searched topic with regards to Django serialization. It is simple to do (as Luke provides above), but my concern is that the API should be polymorphic to make things more succinct and understandable. Right now the `serialize` method seems more along the lines of `seralize_iterable` than `serialize`. Things like this, the lack of ability to specify the depth of recursion when serializing, and the inability to explicitly leave out the PK or class when serializing are why I find myself building up data structures a completely manual way. I don't want to have to answer to my software users, "What is the PK for?", or for people to have to see the the class of the data they're using. It might not hurt, but it's similar to going to McDonalds and seeing the soda box on the counter next to the fountain drinks. It wouldn't make my Coca-Cola any different but there's a reason they put it under the counter. I'm sorry to keep griping (especially since I'm off topic now) and I appreciate all the work you Django developers do to make my life easier at no cost to me, but I see this area as really lacking. I would love to add this polymorphism to the framework but I won't work in a modified framework so I'll only do it that way if you are willing to put it in the trunk. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Serialization of single object instead of only querysets.
Will do. Piston looks pretty cool. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Moving all validation into the model layer.
My idea is probably not unique and Django is already moving in this
direction. I apologize if this is the case.
I have thought for a year, pertaining to Django, about one thing: Why
doesn't validation propagate from the lowest level? Why should this
have to take place at a higher level? What happens with I want to do
things without using forms? Then, Django 1.2 came from the heavens
with validation in the models (which I currently use and love). The
only problem is that it still handles all validation (except the
basics "This field is required" validation) in the form level and a
special model field's only real functionality (outside of choosing a
DB column type and serializing if necessary) is to specify the form
field, which then does the validation necessary.
For instance, in the case of IPAddressField:
# Form
class IPAddressField(CharField):
default_error_messages = {
'invalid': _(u'Enter a valid IPv4 address.'),
}
default_validators = [validators.validate_ipv4_address]
# Model
class IPAddressField(Field):
empty_strings_allowed = False
description = _("IP address")
def __init__(self, *args, **kwargs):
kwargs['max_length'] = 15
Field.__init__(self, *args, **kwargs)
def get_internal_type(self):
return "IPAddressField"
def formfield(self, **kwargs):
defaults = {'form_class': forms.IPAddressField}
defaults.update(kwargs)
return super(IPAddressField, self).formfield(**defaults)
I would rather use:
# Form
# Nothing, the model field could just use a CharField() instance in
this case.
# Model
class IPAddressField(Field):
default_error_messages = {
'invalid': _(u'Enter a valid IPv4 address.'),
}
default_validators = [validators.validate_ipv4_address]
empty_strings_allowed = False
description = _("IP address")
def __init__(self, *args, **kwargs):
kwargs['max_length'] = 15
Field.__init__(self, *args, **kwargs)
def get_internal_type(self):
return "IPAddressField"
def formfield(self, **kwargs):
defaults = {'form_class': forms.CharField}
defaults.update(kwargs)
return super(IPAddressField, self).formfield(**defaults)
Is this the direct that Django's validation is moving to, or am I
thinking of this all wrong?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Moving all validation into the model layer.
BTW, I am aware of the ability to create your own custom model field
class with a custom `validate()` method like my following example. I'm
also aware of using a model's clean() method to raise logical
validation errors, like if their email is a gmail address and they
they specify that they are a Yahoo user, you might raise
ValidationError("You liar. You use Gmail"), and so on.
My custom field and below an explanation of another pitfall of form
validation:
class CurrencyField(models.DecimalField):
"""
Only changes output into a quantized format. Everything else is
the same.
Later I will possibly add currency symbol support.
"""
description = 'A double decimal representing money'
__metaclass__ = models.SubfieldBase
def __init__(self, *args, **kwargs):
kwargs['max_digits'] = 8
kwargs['decimal_places'] = 2
super(CurrencyField, self).__init__(*args, **kwargs)
def to_python(self, value):
try:
return super(CurrencyField,
self).to_python(value).quantize(Decimal('0.01'))
except AttributeError:
return None
def validate(self, value, model_instance):
"""
Check for anything other than numbers, a decimal, and a dollar
sign, and
raise a singular error on success.
"""
# This allows for a $ symbol as well (but that's not supported
by forms.fields.DecimalField)
reo = re.compile(r'^\$?\s*((?=\d*\.|\d)\d*(?:\.\d*)?)$')
if not reo.search(str(value)):
raise ValidationError(u'Enter a valid "money value"
consisting of digits a single decimal place and an optional dollar
sign.')
super(CurrencyField, self).validate(value, model_instance)
def get_db_prep_value(self, value):
"""
Remove dollar signs.
"""
return re.sub(r'[\d\.]', '', str(value))
The above model does everything necessary but some of it isn't even
use all of the logic with Django forms. If I'm using forms, the user
cannot put a "$" symbol because before my code can possibly normalize
the data and remove the dollar sign, the user is warned about it not
being a decimal. However, decimal is what makes most sense to use, and
I don't want to have to create a custom form for this model just so
that I can strip a dollar sign from one field.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Moving all validation into the model layer.
@BrettH This is helpful but only gets me to where I'm currently at. I understand there are model validators available, and now I understand why they are the way they are, but what's next? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Moving all validation into the model layer.
Does anyone have interest in this? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Requesting Django to make authorization more flexible and secure for SAAS projects.
I'm developing an SAAS which means that I will have Accounts and those Accounts will have Users. Each account's Users are completely orthogonal to the Users of another Account. When a user logs in, they'll supply an Account ID, a username, and a password so username only needs to be unique with regards to the Account in question. Firstly, is there an app out there or somebody who knows how to conquer this? If so, I would truly appreciate the help or a link, and if so, you can disregard all of the following: Problem 1 (with built-in User object), maybe there is a way around this: A) User of Account 'acme' might have the username "mike" and the user for Account "general mills" might have a user with the username "mike" (since "mike" is a very common name this will certainly happen within the first day of getting clients). I can't control what Accounts' Users decide to make their username and I certainly don't want to make it like domain registration, like if a User has to check if a username is available before creating it (all common names would be taken after the first 100 accounts if the average account had 2-3 users). Problem 2 (security issues): A ) The current system brings up a security issue. if I tell "mike", 'we are sorry "mike" is taken', then he knows there is another "mike" out there, and if I have a list of accounts showcased publicly (which I will), then the new "mike" who tried to sign up will have an easy time brute forcing, because he will have all the account_ids (which needn't be a really secure thing by themselves), a valid username, and only be missing the password. B ) The other security problem is that if a user tries to log in and fails, Django will move on to the next method listed in my "AUTHENTICATION_BACKENDS" setting (which will be the admin), and if they happen to have the username "admin" which is a very common username for an SAAS along with others like "manager" or "owner". If they happen to have the same username and password as mine they'll accidentally be hacked into every system of the SAAS, including non- public functions like billing, etc. I understand this would be very rare to happen with the numbers and all, but it seems like a security vulnerability when you think of something large like 37 Signals (With 10 millions users, this would be bound to happen eventually and would be devastating). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Requesting Django to make authorization more flexible and secure for SAAS projects.
I suppose it was a bit of a question for django users. I apologize for not explaining that part of it. The reason I approached it that way wasn't to get a solution (although I would've gladly accepted one over wanting to change the base) is because I didn't know exactly what to request for my problem. Russ, have you heard of others with similar problems or is this pretty one-of-a-kind. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Requesting Django to make authorization more flexible and secure for SAAS projects.
Oops. That was me who reported the discussion by accident (iPhone). Disregard. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Moving all validation into the model layer.
Ah, Thanks Russell. I'm new to Django Dev stuff and wasn't aware that they don't do features for the next version and bugs for the current beta. That makes more sense though. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Inheritance: Create a way to subclass and override attributes of a parent class.
Problem that exists:
1) I need to subclass `contrib.auth.User` and strip some of the
elements from it, like making `User.username` non-unique for SAAS with
multiple accounts (`MyCustomUser.username` would only be
`unique_together = ('account', 'username')`
(other instances could occur but I don't pretend to understand the
full implications of this minor limitation)
My proposed solution ( which may be idiotic but I'm looking for
feedback / suggestions ):
1) Allow for subclasses of normal models to override attributes of the
parent model. Then, if any attributes exists that override the parent,
simply use the subclass to create the table and treat the parent as an
ABC adding its attributes ( except ones that were overridden of
course ) into the subclass.
P.S. I know Django is in bug-fix mode but I would like to at least see
what all you guys think so that I can come up with some ideas for this
before 1.3 gets underway.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Inheritance: Create a way to subclass and override attributes of a parent class.
@James Well, I won't even try to argue with that, but there has to be a way to conquer problems like this in Django without editing the source code, don't you think? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inheritance: Create a way to subclass and override attributes of a parent class.
@Jacob Thanks for all the links. I appreciate your reply. Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: dbsettings, and user configurable app settings
I don't think that settings are for users. They are for the developer. The type of settings you are looking for really should be set up as part of your application. Users can't choose a DB password or your server's time zone, or which apps are installed. If you're creating an SAAS you'd be better to have a configuration app that has fields for storing account / user specific settings. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.
-1 I personally think that DEBUG mode is the only time anything other than error logging and a 500 page should happen during an exception, unless done with exception middleware, or in the view. For a template to include TRY / END, is definately stripping any resembalence to a MVC architecture from Django. If it's a custom per-page error message that you want, use try: except: in the view, and render the template with a Django message passed in. There shouldn't be an "Oops an error happened so we're doing XYZ because the template said so.", but rather there should be a generic "Oops, an error happened! Please try again". -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Transactions in Model.clean()
First, here's the problem I'm having, and then I'll bring up my request. I have a model that looks like this (using dev version): class SecretModel(models.Model): some_unique_field = models.CharField(max_length=25, unique=True) # Notice this is unique. class MyModel(models.Model): secret_model = models.OneToOneField(SecretModel, editable=False) # spam = models.CharField(max_length=15) foo = models.IntegerField() def clean(self): SecretModel.objects.create(some_unique_field=self.spam) Now if I go do this: MyModel.objects.create(spam='john', foo='OOPS') # Obviously foo won't take 'OOPS' as it's an IntegerField. ERROR HERE MyModel.objects.create(spam='john', foo=5) # So try again here. ... IntegrityError because SecretModel with some_unique_field = 'john' already exists. If there is a way to handle this behavior already, I apologize for wasting your time. Otherwise, I'm suggesting the addition of transaction handling for model methods. Is this reasonable? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Transactions in Model.clean()
@James Bennett I was suggesting a new feature. Is it still not appropriate? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation outside of ModelForms.
Strong 1+ It doesn't seem that the core team is interested in working on Model validation at the moment: http://code.djangoproject.com/ticket/13121 (my failed ticket) The current thinking by the powers that be is that you cannot introduce model-level validation enforcement without breaking the API for existing users. This is simply not true. With ValidationError propagating upwards from the model level, ModelForm would need nothing to do with validation besides displaying the errors to the user. This is the common sense approach to ModelForms anyway, and the only people who would suffer from this migration would be those who have hacked the core from within their code (re-writing methods in their subclasses that shouldn't typically be re-written). If this were the case, you could build all of your data logic into the Model and then an RPC API, a view, or the built-in Admin would all be very DRY and work identically when using your model. Instead you have to rewrite code all over the place and you cannot even abstract correctly as their are too many leaks into the view layer (see http://www.joelonsoftware.com/articles/LeakyAbstractions.html). Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation outside of ModelForms.
On Mar 16, 10:12 am, James Bennett wrote: > On Tue, Mar 16, 2010 at 10:36 AM, orokusaki wrote: > > It doesn't seem that the core team is interested in working on Model > > validation at the moment:http://code.djangoproject.com/ticket/13121 > > (my failed ticket) > > Stop right there and actually go back and *read* all the feedback > you've gotten, because right now you're just flat-out lying. Russell > has, on multiple occasions, asked you, begged you, and pleaded with > you to get proper discussion going on the things you've proposed. > You've refused and instead adopted a method of opening duplicate > tickets and screwing around with the metadata on existing ones, > apparently out of a desire to annoy as many people as possible rather > than get anything useful done. > > If you'll actually pay attention to what others say and actually put > in the time to learn how the Django development process works, you may > be a lot happier with the results. If instead you just continue what > you've been doing, well, I for one will be happy to direct you to some > other framework that's willing to put up with such antics. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." Actually I'm not lying. Russell hasn't given me any feedback regarding my idea or patch. I didn't simply reopen tickets. Russell changed my ticket to a documentation ticket, so I opened a new ticket to discuss that which he avoided in his discussion. This kind of ego-driven closed mindedness is probably why Django has a low rated community for being such a popular framework. If one person could give me a good (non-formality related) reason for Russell to dismiss my ticket in aprox 2.5 minutes, I would stop complaining about it. It isn't because of OCD that I want this bug fixed. It is because it won't break compatibility, it takes about 5 minutes, and it adds so much value (with respect to its simplicity). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation outside of ModelForms.
On Mar 16, 10:16 am, Harro wrote: > Just my brainfart when looking at this: Can't you simply add a pre > save signal to call the full clean method? > > Dunno if that will work or not, just the first thing I would try. > > On Mar 16, 5:12 pm, James Bennett wrote: > Hey James, I've not used signals yet so I don't know where they fit in the control flow. My first guess is to say no it wouldn't work because I couldn't imagine that pre_save would be called while ModelForm was listening for ValidationErrors. This would be hackish IMHO also, but I'll give it a try though when I get back to my comp (on phone). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation outside of ModelForms.
Thanks James, I'll focus on this here and see what I can come up with. Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Validate a form's excluded fields if a value is present
I'm working on an SAAS project, and there is an ``account`` attribute (foreign key) on every model in the project (similar to those who have a ``user`` or ``created_by`` attribute on every model). ``account`` is added to the request object using a MiddleWare class. When I'm writing views, I have to do this in each view: if request.method == 'POST': form = SomeSpamForm(request.POST) form.instance.account = request.account if form.is_valid(): instance = form.save(commit=False) try: instance.full_clean() except ValidationError, e: form._update_errors(e.message_dict) else: instance.save() I admit that I tend to be a bit OCD about coding style, but I think most programmers would agree that doing that in every single view is a very bad idea, especially if you ever intend on upgrading Django in the future. Imagine having 178 views in 19 apps in a project with that same code, and updating every single one. Of course I could write some sort of monkey patch and pray, but instead I thought of what might be a good solution: In forms.models.BaseModelForm._get_validation_exclusions() ( Defined on line # 266 in SVN) you'll find: 283 # Exclude fields that aren't on the form. The developer may be 284 # adding these values to the model after form validation. 285 if field not in self.fields: 286 exclude.append(f.name) Couldn't this be changed to: 283 # Exclude fields that aren't on the form. The developer may be 284 # adding these values to the model after form validation. 285 if field not in self.fields and not self.cleaned_data.get(field, None): 286 exclude.append(f.name) This would allow me to do this instead of my above example: if request.method == 'POST': form = SomeSpamForm(request.POST) form.instance.account = request.account if form.is_valid(): form.save() That seems way better than manually running validation outside of the excellent ``ModelForm`` built-in error handling. I'm not trying to brown nose here (OK, I am a little), but ``ModelForm`` is so great to use that it's a shame to have the best part (validation) leak into my views. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Validate a form's excluded fields if a value is present
Let me just say that my non-patch above is just an abstract idea, and I don't know if it will work like that without other changes, but I think it gets the idea across. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Validate a form's excluded fields if a value is present
Hey Russ, I'm not on the model.full_clean stuff anymore, and I apologize for burning so many cycles on that point when you're in the middle of 1.2 dev. I'm just wondering if what I proposed above sounds reasonable. The form validation turned off completely for fields that aren't included makes it hard to do custom things. It makes sense by default but it would be nice if there was a way to override it or if it was intelligent to whether there was a value or not. ,Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Validate a form's excluded fields if a value is present
Thanks Jacob, I'll give that a try. On Apr 1, 7:44 am, Jacob Kaplan-Moss wrote: > On Thu, Apr 1, 2010 at 3:11 AM, Russell Keith-Magee > > wrote: > > Melodrama aside, as we've told you before, the docs clearly say that > > full_clean() isn't called by form.save(). The docs also give you the > > reason - backwards compatibility. > > > I don't deny that it would be *really* nice to be able to > > automatically call full model validation on a model on form save - the > > problem is that we can't do that while retaining backwards > > compatibility. > > Well, *we* can't... but *users* can: just override your form's > ``clean`` method, and call ``full_clean`` from there. > > In general, if you find yourself doing the same thing over and over in > different views, it's a sign that you're operating at the wrong level > of abstraction. In this case, solve the problem once by overriding > what you need on the form, and then let your views be as "pretty" as > you'd like. > > Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Validate a form's excluded fields if a value is present
On Apr 2, 2:00 am, Russell Keith-Magee wrote:
> The broad goal is certainly reasonable and desirable. It's really a
> matter of finding a way to make it work that doesn't involve
> completely breaking (or disfiguring) the API that we already have.
>
> Yours,
> Russ Magee %-)
I've been working on this since last night, and I came up with a
decent idea, but there is one serious flaw:
My version would be used like this in a view:
form = SomeModelFormSubClass(request.POST, extra_data={"some_field":
"Some Value"}) # This would work OK, but see the next example
The patch would be to use ``kwargs.pop('extra_data', None)`` to add
subsequent fields back to the form, and un-exclude them from
validation. The problem I ran into before even beginning work on
implementation was this:
form = SomeModelFormSubClass(request.POST, extra_data={"created_by":
request.user}) # Doesn't work because it's expecting a raw value (in
this case, an integer for the ``auth.User.pk``)
The problem is that it in the case of a foreign key (which is where
this would be used most) you have to pass the ``request.user.pk``, but
that doesn't seem natural to do at all. What's your thought on this.
Should it be handled magically behind the scenes like (in
``__init__()``):
extra_data = kwargs.pop("extra_data", None)
if extra_data:
from django.db.models.fields import Field
for key, value in extra_data.items():
if isinstance(value, Field):
value = value.get_form_value()
# Now we can do processing to add the
# field back into the form validation, and
# something to ensure it gets put into
# self.cleaned_data, or set a flag for later
# (haven't checked the order of all that yet)
What's your thoughts? With a little bit of guidance, I can work up a
patch and test it.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Validate a form's excluded fields if a value is present
Russ, I think you're 100% right, and the "wrong place" part hit the nail on the head. This morning I got really frustrated because I couldn't quite see the big picure yet pertaining to the ORM and it's relationship with ModelForm, partly because there is so much going on with state changes and you know how it is trying to understand somebody else's code. To add to the problem is the possibility of a missunderstanding of the API developers who could think extra_data will take care of them. I suposedly I didn't really think of how this might relate (or not relate) with fields other than a foreign key (user, etc), and what a user would think of an error message like"'Tracking Instance ID' has 16 digits but should have only 12" while filling out a contact form or something like that, and I suppose you can't anticipate every possible runtime error either. With that, do you think it's something worth pursuing. I admit I do like the idea of using the instance passed into the form much more. I just have such a large couple of projects coming up that DRY really comes to mind when using try: instance.full_clean(). P.S. sorry for the noobish formatting on this one. IPhone apparently doesn't have backtick ;( -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
High Level Discussion about the Future of Django
This is a bit abstract, but I'd like to bring up this idea, and firstly let me say that I don't intend to waste the time of the major contributors (unless you want to join in of course). I mostly want to get an idea of what some of the contributors/feature proposers out there are thinking of, in a sort of fly by the seat of your pants way. Through reading some of the ideas/problems on this group (including my own) I've noticed that some tend to be A) too far in the future, B) too abstract, C) (very important) Backwards incompatible, D) (very important) Too much architecture changes. The discussions tend to turn from macro to micro very quickly because of some of the existing constraints. 2 thoughts came to mind: 1) What if every major element could be re-factored for better extensibility (and perhaps speed as well) without regard for the backwards compatibility. 2) Imagine the progress that could be made if the existing code base was able to be re-factored in one week (impossible of course, but hypothetically speaking), knowing everything that the developers know now. I know neither of those is possible at the moment, but take those two ideas (rules) in mind, and talk about what you'd add / change / make better / etc. Perhaps this is way more 2.0 than even 1.3, but I wanted to get a very early look through foggy goggles into the future so that I can come up with ideas. I've been bombarding Russell K M with questions, thoughts, etc that are just very poorly timed with 1.2 Beta and all, and I want to step back and really prepare for next time. 2 related questions for anyone who cares to answer: 1) Is anything allowed to become non-backwards compatible during a .x release? (ie, from 1.2 to 1.3 or 1.4) 2) When will 2.0 development begin? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Validate a form's excluded fields if a value is present
I've been brainstorming (ie, drinking more coffee than I should), and what I came up with to be the best (IMHO) solution for A) Less confusion, and B) Less risk of API breakage is: ModelForm.is_valid(include_all_fields=True) or ModelForm.is_all_fields_valid() and neither are going to be an issue to add in the future if the API is locked, so I'm tabling the idea and I'll bring it back up in the 1.3 discussion. Thanks for spending time on this with me this week. Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
@Everyone who has commented here. I never intended to cause any animosity and I really appreciate everything that the core team does for us all. @Jacob I really do intend to write code. I make money doing non-Django development but I love Django so much that I spend 25+ hours a week not getting paid just so I can learn to adopt Django and eventually replace my income with Django development. I think I might even be part pony (DNA testing underway). There are just certain elements of Django that I feel (slightly) holds back a developer of large multi- tenant architecture, which could be a really big way to get major enterprises on-board, and this is where I intend to contribute the most. I just don't have the time (or money after Uncle Sam's 30k this March) to spend on contributing if I'm not sure my ideas will be accepted. This is why I want to spend a little time getting the 5,000 foot view so that my ideas are in sync with what users want, what the core team will accept and what works best with ``from future import *``. If I spend 100% more time on preparing to save 50% of my time, I'll be happy because I've learned more. @Russell Thanks for indulging in conversation, if just for the meta thoughts, this is precisely the sort of macro conversation that helps me understand the Django process's rationale. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Customizable error message for ``unique_together`` constraints
The idea is basically to allow for the customization of the error
message that's raised during ``validate_unique()``.
Example Error:
Widget with this Account and Name already exists.
More Useful Error:
You already have a Widget with this Name.
(The only key difference is that if a field is hidden like "Account",
I don't necessarily want the client to see it.)
The only idea I have for a solution is:
class Meta:
unique_together = (('account', 'name', 'You already have a
Widget with this Name.'),)
orokusaki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Customizable error message for ``unique_together`` constraints
Thanks for the replies guys. I'll follow the progress of that ticket.
On Apr 12, 5:38 am, Karen Tracey wrote:
> On Sun, Apr 11, 2010 at 11:10 PM, Russell Keith-Magee <
>
>
>
> freakboy3...@gmail.com> wrote:
> > On Mon, Apr 12, 2010 at 10:15 AM, orokusaki
> > wrote:
>
> > > The only idea I have for a solution is:
>
> > > class Meta:
> > > unique_together = (('account', 'name', 'You already have a
> > > Widget with this Name.'),)
>
> > [snip]
>
> > That said - my initial reaction is that while I agree with the use
> > case, I'm not a huge fan of the syntax - There is not syntactic
> > separation between column names and error messages; while that isn't
> > necessarily syntactically ambiguous, it's certainly conceptually
> > ambiguous.
>
> Agreed on the objection to that proposed syntax.
>
> Just for reference, there is a ticket for customizable unique error
> messages, #8913. Whatever is eventually done here needs to consider both
> plain unique and unique_together messages -- the ticket at the moment only
> seems to consider the former, but it would not make sense to add support for
> that without also doing the unique_together case.
>
> Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
When I first started posting things on trac, I put up a request that took me an hour to create, explaining the justification, as well as putting the code in there. I didn't know how to make a patch, and I went about it the wrong way, but regardless of that, I put a lot of thought into it. Less than 3 minutes after I posted it, it was closed and resolution set to `wontfix`. It was an extremely minor change that didn't break any backwards compatibility, but I didn't follow the right procedures, so wham, gone. I tend to agree with Kevin's assertion that it's not worth spending time developing when you don't know if your ideas will be thrown in the trash, but I won't complain about it because everything these people do for Django is free to us, and if they weren't hardcore, the framework could have turned into muck by this point (with the number of feature requests out there). After a few rounds of doing that, I realized that people like Russell, who appear to be closed minded at first glance, are really not closed minded at all, but just overworked by tickets and don't have extra time to do every single ticket. I believe this is primarily because for every added feature, tons and tons of code has to be changed / added to keep everything backwards compatible with code from a year ago. I think I speak for a pretty broad user base when I say that folks who use Django are bleeding edge developers who want cool stuff, and don't mind paying a little extra to have it. It isn't like IBM and Microsoft are using Django for huge distributed projects, and upgrading all their clients to the latest version each week. And, again back to Kevin's point; if they are upgrading quickly, they are the types that understand the value of doing so. If the core team doesn't want to change the backwards compatibility policy a tiny bit to accommodate faster paced code ( keeping up with the Jone's and such, such as RoR 3.0 ), it might be worth investing the time to start a fork. A little competition for the core team wouldn't hurt them a bit. It would relieve a little of the stress of being bombarded by tickets for things that are not possible for a whole year, etc. I would only suggest that if you were to go this route, to do so in a way that isn't harmful to Django as a whole (e.g. making empty promises will leave a bitter taste and ruin the name). On Apr 15, 12:57 pm, Kevin Howerton wrote: > "You seem to be suggesting that a fork will somehow magically fix the > speed of Django development. I ask you: who is going to work on this > fork?" > > I think a hostile fork is almost a certain outcome if development > continues as it has. Not only is the resistance to make backwards > incompatible changes in future releases a bad policy for the quality > of the framework, but the behavior in trac has a negative effect on > community contributions. > > The level of resistance I see to change or outsider code contribution > is an enormous de-motivator for people (like me) to want to make any > contributions in the first place. Why should I contribute a patch to > your flawed architecture if I'm going to be talked down to, ridiculed, > then eventually have the patch rejected because it breaks code in some > edge-use-case? > > Personally I believe my time might be better spent developing a fork, > than arguing over clear flaws in architecture decisions that "can't be > changed". > > It's a good idea to avoid breaking backwards compatibility in point > releases, but as far as major releases go ... I whole heartedly > encourage it. If keeping backwards compatibility was a good idea, my > macbook pro would have a 5.12" floppy drive, a 3.25" drive, a jazz > drive, it would accept serial and adb plugs and maybe have a > display mode to emulate those green crt monitors of yore. > > Good software is about removing flaws, improving the architecture, and > learning from past mistakes. If this comes at a price, then pay. > > -k > > On Wed, Apr 14, 2010 at 9:25 AM, Russell Keith-Magee > > wrote: > > On Wed, Apr 14, 2010 at 8:34 PM, veena wrote: > > >> I know there's django deprecation policy nicely documented > >>http://docs.djangoproject.com/en/1.1/internals/release-process/#inter... > > >> But what I don't know is how you discover it. Is it described > >> somewhere in the text or the video from conference? What were the > >> reasons to have this deprecation policy? Was there any user research? > >> Research of when the django users upgrade, what are the main problems > >> of upgrades and how they imagine upgrading should work? > > > The policy was arrived at after a debate between the core team, based > > on how the core team believe a well-behaved project should behave. For > > the record, it wasn't much of a debate, either - we were all pretty > > much in agreement on the core points from the beginning. > > > In the opinion of the core, well-behaved projects don't require > > massive rewrites (or worse - subtle bug chasing efforts) every
Re: High Level Discussion about the Future of Django
Russell, This is what I meant by "straw hat" the other day. You took what I said out of context in a sly attempt at ignoratio elenchi. I made it clear in the first paragraph that **I started out thinking you were closed minded**, but then said that **I later realized that you were just busy**. I was bringing into question the policy of backwards compatibility, not your personality. It is you who has been engaged in ad hominem, not I. This sort of behavior is not conducive to a productive development environment. The real points you should be taking from all these conversations: 1) People don't like slow progress, but also want stability. Maybe it's time to revisit the policy to find a better balance, so that users aren't always recommended to use the trunk in production websites. 2) It seems that others are concerned with SVN and want to use a definative version, e.g. 1.2.2, instead of some r5481849448 number, and without having to wait for 6 months for the official 1.2 release. 3) People specifically aren't contributing because they know that every attempt they make will get them exactly nowhere, except close lined. Perhaps problem 1 could be solved by solving this problem with a slightly more open policy, instead of closing tickets 5 seconds after they're open. 4) The attitude projected at developers gives the idea that Django is for the core team only, and that users are graced with the ability to use Django. While the contribution is much appreciated, the attitude is harmful to the core team and to the user base. On Apr 16, 9:31 pm, Russell Keith-Magee wrote: > On Sat, Apr 17, 2010 at 6:02 AM, orokusaki wrote: > > When I first started posting things on trac, I put up a request that > > took me an hour to create, explaining the justification, as well as > > putting the code in there. I didn't know how to make a patch, and I > > went about it the wrong way, but regardless of that, I put a lot of > > thought into it. Less than 3 minutes after I posted it, it was closed > > and resolution set to `wontfix`. It was an extremely minor change that > > didn't break any backwards compatibility, but I didn't follow the > > right procedures, so wham, gone. > > I'm going to stop you there. You repeatedly *asserted* that it was > backwards compatible. We (Joseph and I) *repeatedly* told you that we > didn't think it was, and we *repeatedly* told you to take the > discussion to django-dev, and you *repeatedly* didn't, and we > *repeatedly* pointed you at the contribution docs to tell you why we > were saying you should take it to django-dev, and you *repeatedly* > didn't... until you finally did, at which point, we demonstrated why > your idea wasn't backwards compatible, and -- unless I'm mistaken -- > you agreed. > > Please don't characterize what Joseph and I did as arbitrary or closed minded. > > > If the core team doesn't want to change the backwards compatibility > > policy a tiny bit to accommodate faster paced code ( keeping up with > > the Jone's and such, such as RoR 3.0 ), > > Django's backwards incompatibility policy doesn't mean *no change*. It > means *no sudden change*. There are *many* examples in Django 1.2 > alone of features that are being deprecated or altered in ways that > will ultimately be incompatible. Code written for Django 1.0 won't run > unmodified in Django 1.4 due to changes in admin registration, > messaging, CSRF, and many other features. However, these changes are > introduced as a series of progressive enhancements rather than sudden > changes. This enables use to provide ample active warnings advising > that code changes will be required. It also avoids the need to > introduce "USE_NEW_BEHAVIOR" settings switches that require us to > maintain two implementations in parallel and in perpetuity. > > We're open to any proposal to change the status quo - as long as it > can be done gradually and gracefully. If you think hard enough, *most* > problems can be fixed in this way. Those that can't are unfortunate > warts, but that's the price we pay for having a stable platform. As > Jacob said, that's not a claim that Django-style stability is > "correct" - it's just the policy we have adopted based on our > particular priorities. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/
Re: High Level Discussion about the Future of Django
Russell, I apologize for the apparent argumentum ad nauseam. I am not trying to be sly. I am just looking for open dialogue about ideas and I feel like the door is closed and caucus is frowned upon. This is the only way I feel like I can get any floor time. The tickets I create get closed quickly, and if I open better, more refined ones, they're closed as duplicates. I really am not against, per se, the backwards compatibility guidelines, and I understand that there would be just as many folks upset if it were too lax. I just think that it ought to be revisited. Call this abstract, but that is only because I don't have the "correct" solution. The 'full_clean' stuff is the only thing that really got me fired up. My change was not backward incompatible. ModelForm._post_clean() currently calls nearly the exact same code that is in Model.clean() instead of simply calling Model.clean() which would fix the entire problem in less than "one hour". If I'm wrong, then explain to me how it breaks backward compatibility instead of simply erasing the docs. I can't help but feel like you did this to punish me for not following protocol, since you've not given my tickets more that 3 minutes. I've spent much more than 18 months thinking about a lot of things, but I'm always open to suggestion from eager hellers with a vested interest in helping me solve a problem. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
Russell, With all respect, you still haven't addressed my main concern: You told me that it was because of backward compatibility that this simple change couldn't be put in the trunk. It is backward compatible. If I'm wrong, it would suffice to have a simple explanation of what it breaks. On Apr 19, 2:17 am, Russell Keith-Magee wrote: > On Mon, Apr 19, 2010 at 1:27 PM, orokusaki wrote: > > Russell, > > > I apologize for the apparent argumentum ad nauseam. I am not trying to > > be sly. I am just looking for open dialogue about ideas and I feel > > like the door is closed and caucus is frowned upon. This is the only > > way I feel like I can get any floor time. The tickets I create get > > closed quickly, and if I open better, more refined ones, they're > > closed as duplicates. > > > I really am not against, per se, the backwards compatibility > > guidelines, and I understand that there would be just as many folks > > upset if it were too lax. I just think that it ought to be revisited. > > Call this abstract, but that is only because I don't have the > > "correct" solution. > > > The 'full_clean' stuff is the only thing that really got me fired up. > > My change was not backward incompatible. ModelForm._post_clean() > > currently calls nearly the exact same code that is in Model.clean() > > instead of simply calling Model.clean() which would fix the entire > > problem in less than "one hour". > > > If I'm wrong, then explain to me how it breaks backward compatibility > > instead of simply erasing the docs. I can't help but feel like you did > > this to punish me for not following protocol, since you've not given > > my tickets more that 3 minutes. I've spent much more than 18 months > > thinking about a lot of things, but I'm always open to suggestion from > > eager hellers with a vested interest in helping me solve a problem. > > And if you want that answer, you've been told *many* times what you need to > do. > > If you choose to think of this as punishment for not following > protocol, that's up to you. I prefer to think of it as not encouraging > developers to engage in practices that we know (from experience) to be > counterproductive to the development process. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
CURRENT VERSION OF API STABILITY POLICY: The release of Django 1.0 comes with a promise of API stability and forwards-compatibility. In a nutshell, this means that code you develop against Django 1.0 will continue to work against 1.1 unchanged, and you should need to make only minor changes for any 1.X release. SUGGESTED VERSION OF API STABILITY POLICY: The release of Django 1.0 comes with a promise of API stability and forwards-compatibility. In a nutshell, this means that code you develop against Django 1.0 will continue to work against 1.1 unchanged, and you should need to make only minor changes for the 1.2 release. It seems that this small change alone could dramatically decrease the number of hours spent by you guys. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
Absolutely not. I'm saying the following: 1.1 works with 1.0 1.2 works with 1.1 1.3 works with 1.2 and 1.2 works (with slight modifications) with 1.0 1.3 works (with slight modifications) with 1.1 1.4 works (with slight modifications) with 1.2 On Apr 19, 9:31 am, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki wrote: > > The release of Django 1.0 comes with a promise of API stability and > > forwards-compatibility. In a nutshell, this means that code you > > develop against Django 1.0 will continue to work against 1.1 > > unchanged, and you should need to make only minor changes for the 1.2 > > release. > > So you're proposing that 1.2 be the last backwards-compatible release, > and that 1.3 be incompatible (if necessary) with 1.2? > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
Yes, thank you David. On Apr 19, 9:38 am, David Zhou wrote: > On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss > wrote: > > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki > > wrote: > >> The release of Django 1.0 comes with a promise of API stability and > >> forwards-compatibility. In a nutshell, this means that code you > >> develop against Django 1.0 will continue to work against 1.1 > >> unchanged, and you should need to make only minor changes for the 1.2 > >> release. > > > So you're proposing that 1.2 be the last backwards-compatible release, > > and that 1.3 be incompatible (if necessary) with 1.2? > > I think he's saying that 1.3 will work with 1.2 but not (necessarily) > with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0. > > The specific number of point releases to remain compatible with can > probably be quibbled over, but I think the point is that maintaining > across the entirety of 1.x releases when point releases take this long > can be untenable for good forward momentum. > > -- dz > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
Jacob, With respect, If I simply "trusted" folks, I would be: 1) making exactly 120k less per year, as my previous employers told me to "trust" them right before they went out of business and fired everyone 2) a lot less intelligent than I am 3) ignoring the advice of Benjamin Franklin "it is the first responsibility of every citizen to question authority." 4) committing a fallacy of defective induction. I'll stick to the broad advice of those who created the country I live in by convention, and ignore the other reasons. On Apr 19, 10:16 am, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 9:55 AM, orokusaki wrote: > > With all respect, you still haven't addressed my main concern: You > > told me that it was because of backward compatibility that this simple > > change couldn't be put in the trunk. It is backward compatible. If I'm > > wrong, it would suffice to have a simple explanation of what it > > breaks. > > You've been told by three separate developers now that it's not > backwards compatible. It's time for you to trust that we know what > we're talking about and move on. > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Level Discussion about the Future of Django
Ok, problem solved:
``Model.full_clean()``
def full_clean(self, exclude=None, validate_unique=True):
"""
Calls clean_fields, clean, and validate_unique, on the model,
and raises a ``ValidationError`` for any errors that occured.
"""
errors = {}
if exclude is None:
exclude = []
try:
self.clean_fields(exclude=exclude)
except ValidationError, e:
errors = e.update_error_dict(errors)
# Form.clean() is run even if other validation fails, so do
the
# same with Model.clean() for consistency.
try:
self.clean()
except ValidationError, e:
errors = e.update_error_dict(errors)
# Run unique checks, but only for fields that passed
validation.
for name in errors.keys():
if name != NON_FIELD_ERRORS and name not in exclude:
exclude.append(name)
if validate_unique:
try:
self.validate_unique(exclude=exclude)
except ValidationError, e:
errors = e.update_error_dict(errors)
if errors:
raise ValidationError(errors)
``ModelForm._post_clean()``
def _post_clean(self):
exclude = self._get_validation_exclusions()
opts = self._meta
# Update the model instance with self.cleaned_data.
self.instance = construct_instance(self, self.instance,
opts.fields, opts.exclude)
# Clean the model instance and catch any and all fields.
try:
self.instance.full_clean(exclude=exclude,
validate_unique=self._validate_unique)
except ValidationError, e:
# Add the field errors in and NON_FIELD_ERRORS here (I
don't know the ins and outs of how `ValidationError` works).
This single change allows for so much more to be done in the model
layer instead of repetitive views. It allows you to actually do what
the docs say and use `Model.clean()` to do necessary additions to an
instance before it's saving, and without regards to data integrity,
because **this allows for you to wrap `Model.full_clean()` in a
transaction** and trust that it will always be used. I'm no RoR fan,
but Rails' policy of keeping data related logic inside of models is a
very wise one.
On Apr 19, 9:53 am, James Bennett wrote:
> On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote:
> > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote:
> >> With all respect, you still haven't addressed my main concern: You
> >> told me that it was because of backward compatibility that this simple
> >> change couldn't be put in the trunk. It is backward compatible. If I'm
> >> wrong, it would suffice to have a simple explanation of what it
> >> breaks.
>
> > I'd like to second this question. orokusaki suggested a couple of things
> > in ticket #13100, but I'm seconding specifically this comment:
> >http://code.djangoproject.com/ticket/13100#comment:8
>
> The difference between how ModelForm works and how Model works is
> that, if you're overriding clean() on a ModelForm subclass, you don't
> automatically get uniqueness validation -- you have to call up to the
> parent clean(), or manually apply the uniqueness validation in your
> own clean().
>
> In Django 1.0 and 1.1, this is documented behavior:
>
> http://docs.djangoproject.com/en/1.0/topics/forms/modelforms/#overrid...http://docs.djangoproject.com/en/1.1/topics/forms/modelforms/#overrid...
>
> As such, changing ModelForm to always behave identically to, or to
> always call, Model.full_clean() would have to change documented
> behavior. We can't do that in the 1.1 -> 1.2 jump, and for future
> consideration trying to force them to behave identically is probably
> unworkable (better would be to come up with API that lets you
> explicitly control uniqueness validation).
>
> This is why that ticket has been changed to a documentation issue: the
> wording of the documentation with respect to ModelForm and model
> validation is pretty bad right now, and needs to be cleaned up for the
> 1.2 release. And this is why for a month now multiple committers have
> been saying that the proposed code changes are backwards-incompatible:
> ModelForm.clean() and Model.full_clean() *cannot* be made to function
> identically right now without changing documented behavior.
>
> And for the record, my own frustration on that ticket boils down to a
> simple thing: Joseph pointed out there was a backwards-compatibility
> issue, and opted to salvage the most workable solution by changing it
> to a documentation issue. The reporter reverted that. Russell chimed
> in and pointed out that Joseph was probably right and set the ticket
> back
Re: Process discussion: reboot
Firstly, thanks to Jacob for the highly hostile nature of his bedside manor. Secondly, I didn't assert anything. I merely referenced the docs (I suppose this will be another case where you simply adjust the docs to mirror your recent assertion) http://docs.djangoproject.com/en/dev/misc/api-stability/#api-stability On Apr 19, 10:48 am, David Zhou wrote: > On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss > wrote: > > On Mon, Apr 19, 2010 at 10:38 AM, David Zhou wrote: > >> The specific number of point releases to remain compatible with can > >> probably be quibbled over, but I think the point is that maintaining > >> across the entirety of 1.x releases when point releases take this long > >> can be untenable for good forward momentum. > > > I'm pretty annoyed that you think that the policy is to maintain > > backwards compatibility "across the entirety of 1.x releases" because, > > well, that's not the policy. This is documented; see > >http://docs.djangoproject.com/en/dev/internals/release-process/. > > You're right, of course, and I should've fact checked orokusaki's > assertion that that was the current policy. So I'll retract my > previous statements -- those are only applicable given the policy > stated in orokusaki's email. > > -- dz > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
On a broader note, let me give you a bit of history. I started my career as a customer service person. I managed Staples Business Services department in my local Staples. Before I decided to learn programming a couple years ago at 24, I learned a valuable lesson: -- No matter what industry you're in, or what your title is, your real job is "Sales Person". Your second job is "Customer Service", and finally your third job is "[Insert Job Title Here]". When my clients come to me and say "MY SITE SHOULD DO THIS!" my first response isn't "YOU'RE WRONG!". I understand that they're my clients, and they are always right in their own eyes. It's my job to find out where their pain point is, and see if there is a better remedy than what they're suggesting. If there is not, then it's my job to decide if they're truly wrong. If I find out they're not wrong, and I don't have a better remedy, I typically cave to their request rather than going back and changing my proposal to exclude their current request. I'm not saying that the core developers should think of their free, public contributions as a paying client, but it might be good to exercise a little restraint when you feel "annoyed". If I didn't feel so pushed back by the core team, I'd become a big contributor, but instead of writing code, I spend all of my free time arguing, if just to get somebody to level with me and give me a good reason why they're turning my away. I don't claim to be an expert, but in my own eyes, my ideas are gold until somebody can give me a good explanation of why they're not. In the team development process, this constructive feedback is called problem solving. Look at what I was able to achieve in 5 minutes with James' feedback: http://groups.google.com/group/django-developers/browse_thread/thread/f8c747a26aa5d8ed/1397a0785cb09a36 (bottom). If my new version is still bad, take 30 seconds for some more feedback. repeat this across a slough of tickets, and before you know it you have hundreds of problem solvers like me, with vested interests, developing Django piece by piece. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Process discussion: reboot
Jacob, I just refreshed. Please don't kick me. I'm trying to have a dialogue, and I'm not trolling. Django is my life, and I want to help. On Apr 19, 11:20 am, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 12:09 PM, orokusaki wrote: > > Firstly, thanks to Jacob for the highly hostile nature of his bedside > > manor. > > Please, just stop. This doesn't help. > > > Secondly, I didn't assert anything. I merely referenced the docs (I > > suppose this will be another case where you simply adjust the docs to > > mirror your recent assertion) > > Now you're trolling - we've never done this. The documentation is in > SVN and there's a complete historical record. Point to one instance > where we've done this. > > This is your last warning. Keep this up and I'm going to have no > choice but to kick you off this list. > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
I think I can play this: Q: Why is so much valuable time wasted on insulting other people, instead of making money? A: "We are all born ignorant, but one must work hard to remain stupid." Q: Why do folks turn away constructive criticism with a sarcastic snicker? A: "None but the well-bred man know how to confess a fault, or acknowledge himself in an error." Finally: Q: Why are there those who micro manage, those who play follow the leader, and those who have a vacation home in Juno Beach FL, a boat, a Jaguar XKR, 2-3 months of vacation per year, and a wife who is quitting her job to spend time on helping endangered loggerhead sea turtles, just because she can? A: "All mankind is divided into three classes: those that are immovable, those that are movable, and those that move." Giving money to sign holders is never a good idea, but when I handed a filthy bum a dollar fifty or so in change once without his solicitation, and he threw it on the ground in prideful ignorance, I realized then what separated him from me. On Apr 19, 5:23 pm, Bitrot McGee wrote: > Q: When will Django finally have every feature I want? > A: "Ambition has its disappointments to sour us, but never the good > fortune to satisfy us." > > Q: What the fuck is taking so long? > A: "As we enjoy great advantages from the inventions of others, we > should be glad of an opportunity to serve others by any invention of > ours; and this we should do freely and generously." > > Q: Should certain Trac fields only be editable by commiters? > A: "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > > -- > > I hope this attempt to lighten the mood isn't too distracting. > > To the core team: your efforts are so, so appreciated. Benjamin > Franklin (et al.) know that you have a lot of other things you could > be doing, and that working on Django is too often thankless. Thank > you! You all deserve many, many IRL ponies. A herd of ponies. > > To everyone: I'd like to close with a quote by Richard Penn: "We must, > indeed, all hang together, or assuredly we shall all be forced to use > Rails separately." Please keep that in mind. It seems relevant for > some reason. > > ~Bitrot > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
Since you have a PhD in computer science and you're seven years older than me, and you work for me, for free, while I have exactly zero computer science credits (or anything related), I think "the internets" award goes to you. On Apr 19, 8:23 pm, Russell Keith-Magee wrote: > On Tue, Apr 20, 2010 at 7:23 AM, Bitrot McGee wrote: > > Q: When will Django finally have every feature I want? > > A: "Ambition has its disappointments to sour us, but never the good > > fortune to satisfy us." > > > Q: What the fuck is taking so long? > > A: "As we enjoy great advantages from the inventions of others, we > > should be glad of an opportunity to serve others by any invention of > > ours; and this we should do freely and generously." > > > Q: Should certain Trac fields only be editable by commiters? > > A: "Those who would give up Essential Liberty to purchase a little > > Temporary Safety, deserve neither Liberty nor Safety." > > > -- > > > I hope this attempt to lighten the mood isn't too distracting. > > You, good Sir, win the internets. :-) > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
Thanks a lot for standing by your list policy here BTW. On Apr 19, 8:23 pm, Russell Keith-Magee wrote: > On Tue, Apr 20, 2010 at 7:23 AM, Bitrot McGee wrote: > > Q: When will Django finally have every feature I want? > > A: "Ambition has its disappointments to sour us, but never the good > > fortune to satisfy us." > > > Q: What the fuck is taking so long? > > A: "As we enjoy great advantages from the inventions of others, we > > should be glad of an opportunity to serve others by any invention of > > ours; and this we should do freely and generously." > > > Q: Should certain Trac fields only be editable by commiters? > > A: "Those who would give up Essential Liberty to purchase a little > > Temporary Safety, deserve neither Liberty nor Safety." > > > -- > > > I hope this attempt to lighten the mood isn't too distracting. > > You, good Sir, win the internets. :-) > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
