Re: Validation Aware Models and django.forms on steroids
Brantley Harris wrote: > Maybe it's a philosophic question, but I see it best > defined in the "model" space because then it provides a modular > process for views to leverage. Manipulators can (and do) serve not only as model savers. They can authorize, register, send mail etc. Manipulator is just a very good pattern for dealing with form POSTs. I think that manipulators that save models should still look like other manipulators and this logic is best suitable to live in a view. If we relay an entire model manipulation into the model itself then we'll get two kinds of manipulators: those living in views and those living in models. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
I agree and disgree. :) I like James Bennetts's example a lot, but I'd like it more if the form class were ModelForm, descending from a more general Form class that would look much like the base Manipulator class of today. I'm afraid that I find the idea in Brantley Harris's proposal of raising a Form as an exception as a form of flow control really counter-intuitive. Apologies and it's just my opinion of course, but it has a sort of "too clever" feel to me. Also, exceptions are very expensive, and I don't see the practical benefits of that usage pattern over something like: form = Poll.CreateForm(request) errors = form.validate() if errors: ... else: ... Last up, a question for James. In your example you have exclude_fields and extra_fields. What if I want to bind a different form field type to a model field? What would the synax be for that? Something like: class CrazyArticleForm(ArticleAddForm): override_fields = ( myapp.CrazyField(field_name='title', model_field='title', ) Maybe? (I don't like 'override' there but I'm not sure what else to call it.) And in service of that sort of thing, I think at the input conversion phase, the form should delegate to each field to pull its data out of the request, since some fields may be singular in concept but spawn multiple html elements. That brings up a related question: can one form field bind to multiple model fields? (I'm thinking of file upload, where you get can back a filename and a mime type and the file contents). JP --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
> I'm afraid that I find the idea in Brantley Harris's proposal of
> raising a Form as an exception as a form of flow control really
> counter-intuitive. Apologies and it's just my opinion of course, but it
> has a sort of "too clever" feel to me. Also, exceptions are very
> expensive, and I don't see the practical benefits of that usage pattern
> over something like:
Actually that was one of my favorite pieces. I think it captures what's
going on in a very intuitive way: try to create/update, if that fails,
redisplay with errors. Maybe a good solution to the "too clever"
feeling would be to, instead of raising a Form as an exception, raising
a real error, with a property/accessor to get at a partially-completed
form?
try:
m = Poll.CreateManipulator()
poll = m.save( req.POST ) #, req.user?
return HttpResponseRedirect( '/poll/%d/' % poll.id )
except ManipulatorError, e:
# print e.errors
return render_to_response( 'poll/create.html', {'form': e.form} )
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: db_index not creating indexes with syncdb
Yes, that worked. But the documentation always seems to recommend running ./manage.py syncdb after you set up your models. It should also create any indexes you have defined. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: db_index not creating indexes with syncdb
The tutorial says and mentions that it creates indexes explicitly. The syncdb command runs the sql from 'sqlall' on your database for all apps in INSTALLED_APPS that don't already exist in your database. This creates all the tables, initial data and indexes for any apps you have added to your project since the last time you ran syncdb. syncdb can be called as often as you like, and it will only ever create the tables that don't exist. It looks like syncdb has a bug in that it doesn't create the indexes -- at least on MySQL. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
Dan Watson wrote: > Actually that was one of my favorite pieces. I think it captures what's > going on in a very intuitive way: try to create/update, if that fails, > redisplay with errors. I think the piece on which I agree with JP is that a _form_ serving as an exception is counter-intuitive. I would prefer an exception to be an error dict that is then used to display them. Consider a form working over Ajax. In most cases you don't want to redisplay the whole form with errors but give out just errors serialized as JSON or XML. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: Validation Aware Models and django.forms on steroids
On 8/24/06, JP <[EMAIL PROTECTED]> wrote: > I like James Bennetts's example a lot, but I'd like it more if the form > class were ModelForm, descending from a more general Form class that > would look much like the base Manipulator class of today. I think you're confusing me with someone else... > I'm afraid that I find the idea in Brantley Harris's proposal of > raising a Form as an exception as a form of flow control really > counter-intuitive. Apologies and it's just my opinion of course, but it > has a sort of "too clever" feel to me. Also, exceptions are very > expensive, and I don't see the practical benefits of that usage pattern > over something like: The benefit, as I see it, is that it's much simpler and much more descriptive of what's actually going on; you've got some data, you're trying to save an object from it. Which, logically, translates into a try/except block around the form's 'save' method; that makes the code crystal-clear on what you're actually trying to do. The expense of an exception is something to talk about, but I think it does need to be talked about in the context of how often most applications actually write to the DB, and how many of those writes are mediated by a manipulator. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: Validation Aware Models and django.forms on steroids
On 8/24/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > I think the piece on which I agree with JP is that a _form_ serving as > an exception is counter-intuitive. I would prefer an exception to be an > error dict that is then used to display them. I'm not so sure about that. The form itself was the thing that was "bad" and needs to be dealt with, so why *shouldn't* it be the exception? > Consider a form working over Ajax. In most cases you don't want to > redisplay the whole form with errors but give out just errors serialized > as JSON or XML. try: p = poll_form.save(poll_data) return HttpResponse(simplejson.dumps(p), mimetype="application/javascript") except Form, form: return HttpResponse(simplejson.dumps(form), mimetype="application/javascript") -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
On 8/24/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Brantley Harris wrote: > > Maybe it's a philosophic question, but I see it best > > defined in the "model" space because then it provides a modular > > process for views to leverage. > > Manipulators can (and do) serve not only as model savers. They can > authorize, register, send mail etc. Manipulator is just a very good > pattern for dealing with form POSTs. > > I think that manipulators that save models should still look like other > manipulators and this logic is best suitable to live in a view. If we > relay an entire model manipulation into the model itself then we'll get > two kinds of manipulators: those living in views and those living in models. > I think this is the crux of the problem, honestly. We have to decide if manipulation should be in the "model" space or the "view" space (or is that controller? whatev.). I rather see it in it's own space... MMVC anyone? But you're right, they can certainly be used for other uses, which is why the Manipulator class I made allows you to define whatever save() you might want, including just returning the data so that you can do something with it in the view. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
James Bennett wrote: > I'm not so sure about that. The form itself was the thing that was > "bad" and needs to be dealt with, so why *shouldn't* it be the > exception? It just feels right to me... When you're opening a file and you, say, don't have permission you get OSError, not this "bad" file as an exception. > try: > p = poll_form.save(poll_data) > return HttpResponse(simplejson.dumps(p), > mimetype="application/javascript") > except Form, form: > return HttpResponse(simplejson.dumps(form), > mimetype="application/javascript") Well, of course it's doable. I'm talking about convenience for people's mind. I'm not ready to say that my vision is the only right thing but may be others feel like this also. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
James Bennett wrote: > On 8/24/06, JP <[EMAIL PROTECTED]> wrote: > > I like James Bennetts's example a lot, but I'd like it more if the form > > class were ModelForm, descending from a more general Form class that > > would look much like the base Manipulator class of today. > > I think you're confusing me with someone else... Sorry! I mixed up Joseph, who was quoted in Adrian's email, with your first reply to the message with the quote. Apologies to James and Joseph for the misattribution. I still like the ideas. :) > > I'm afraid that I find the idea in Brantley Harris's proposal of > > raising a Form as an exception as a form of flow control really > > counter-intuitive. Apologies and it's just my opinion of course, but it > > has a sort of "too clever" feel to me. Also, exceptions are very > > expensive, and I don't see the practical benefits of that usage pattern > > over something like: > > The benefit, as I see it, is that it's much simpler and much more > descriptive of what's actually going on; you've got some data, you're > trying to save an object from it. Which, logically, translates into a > try/except block around the form's 'save' method; that makes the code > crystal-clear on what you're actually trying to do. All I can say is that I don't see it that way. For me, raising the form as an exception (or an exception referencing the form) seems unnatural and unintuitive, and much less explicit, readable, etc, than just dealing with the flow of form validation and saving in the same way that Manipulators do now. And it ignores the many uses of forms that don't involve binding a form to single model that validates and saves the form input. I don't think that the view-manipulator interaction is broken, and I think it can be easily adapted to handle model-driven validation and saving, as in Joseph's sample code. So count me as -1 on using exceptions for form processing control, for whatever that's worth. JP --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
On Aug 23, 2006, at 6:25 PM, Adrian Holovaty wrote:
> Let's make this happen!
Indeed!
I've got some thoughts and preferences given all the ideas I've seen,
so here goes... Essentially, I think there's two tasks here:
1. Validation-aware models.
I very much want to be able to validate and save models without the
use of manipulators (or forms or whatever you call 'em). I'd like to
be able to do something like::
p = Person(**data)
try:
p.save()
except ValidationError:
handle_the_error()
The ``Model.validate()`` method that Adrian's started on should
handle this, and also nicely allows models to define custom
validation behavior outside of the manipulator framework (by
extending that ``validate()`` method).
One issue that's been raised is that ``p.save()`` could potentially
raise many validation errors, and ideally those would be communicated
up the extension stack. So probably we'd need a ``ValidationErrors``
exception that encapsulates a bunch of validation errors in a single
exception. ``Model.save()`` could raise one of these, and I'd
imagine that ``Model.validate()`` would do the same.
I think we're well on our way towards making this work. We'd need to
complete the various field-level validation, and then make it active.
2. Simplify forms, and make the word "Manipulator" go away.
Like Adrian, I can't stand the word :) It's just so... Java-ish.
The other thing I can't stand is the whole FormWrapper layer over
Manipulators; ideally the replacement would merge the two.
I quite like Joseph's proposal. I especially like being able to
control which form is used both for generic views and in the admin.
I'm also a fan of the {{ form.html }} shortcut. With some careful
use of nice semantic HTML we should be able to make that shortcut
work nearly all the time.
I'm less hot on the view syntax from Joseph's proposal; it still
seems like more steps than I'd like to use.
Brant's proposal also has some high points; in particular, the
separation of converting data from its POSTed representation is
something that we need to get right; making it an explicit step is
the right way to go.
However, this::
except Form, form:
*really* rubs me the wrong way. To me, this is a pretty counter-
intuitive use of exceptions -- exceptions should be used to indicate
an exceptional situation; not an expected one. Furthermore, PEP 352
(http://www.python.org/dev/peps/pep-0352/) -- which will be complete
in Python 3.0 - requires that exceptions actually extend from
``BaseException``, which introduces weird semantics all its own. I'm
a big -1 to using exceptions for Forms.
So, given all that, I think we ought to use Joseph's proposal as a
starting point, but integrate a few ideas from what Brant came up
with. In particular, here's how I'd add to/change Joseph's outline:
- Add an explicit ``convert()`` step to the ``Form``. It would be
called automatically, but making the step separate would allow
subclasses to override it if necessary, and would also allow code
just convert data (a need I've seen in a few places).
- Figure out a way to make the common-case view code as simple and
streightforward as possible. I'm not sure where to go here, but I
think we can improve on Joseph's idea a bit.
Al-rightly then... thoughts?
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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
JP wrote: > Also, exceptions are very > expensive, while this is true in java or c++, it is not necessarily true in python. even python itself uses exceptions for example when doing a for-loop over an iterable (the iterator's next() method raises StopIteration when it's at the end). gabor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Dynamic Menus...
Don't know if this is a Django question or not, but here is the situation: I am developing an application for a client who is a automobile broker. He wants agents to submit requests for vehicles from the web. The agent will be able to select the make/model of the vehicle. What I want is for the model menus to adjust dynamically depending on the make selected. For example, if the agent selects "Honda" I only the the models menu to show Civic, Accord, Element, ect. How can this be achieved? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
On 8/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Al-rightly then... thoughts? > +1 ValidationErrors with an s, as I've said before: the more errors returned at once, the better. My problem with Joseph's proposal is that I believe it to be too tied to the concept of the Model. Idealy, the Form/Manipulator should not really have anything to do with a Model, except perhaps in the finalization, like in .save(). Also it doesn't end up actually leveraging model-validation. You'd have to define the validation twice, once in the Model, and then once in Field. But leveraging on the Model validation turns out to be rather tricky anyway, even in my proposal. Lo: Let's say I have a dict, named "poll_data" with a data for a new Poll object. And an dict, named "choice_data", which has info for a new choice added in the inline. poll = Poll(**poll_data) errors = poll.save() # We don't get any errors. poll.choice_set.create(**choice_data) errors = choice.save() # But we get some here. So now we return the form with the errors. But the user decides that he can't add his clever poll with a choice that is empty, so he cancels and goes home for the day, expecting that his poll was never created. But alas, it IS created because we did "poll.save()". We could rework it to do poll.validate() instead of saving, but since the Poll then hasn't been created yet, you have to make the Choice without a poll, and then assign it after. Seems like a transaction. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Dynamic Menus...
On Aug 24, 2006, at 2:14 PM, mediumgrade wrote: > Don't know if this is a Django question or not, but here is the > situation: > > I am developing an application for a client who is a automobile > broker. > He wants agents to submit requests for vehicles from the web. The > agent > will be able to select the make/model of the vehicle. What I want is > for the model menus to adjust dynamically depending on the make > selected. For example, if the agent selects "Honda" I only the the > models menu to show Civic, Accord, Element, ect. > > How can this be achieved? It's pretty much a Javascript thing; googling around for "javascript select" or "dynamic select" should find something useful. FYI, you're likely to get much better responses if you post questions of this nature to django-users. django-developers is where we discuss developing Django itself; django-users is for questions about using Django. Thanks! 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
James Bennett wrote: > On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: >> Thoughts/comments/suggestions on Joseph's plan below, and on Brant's >> plan in Trac? > > I think Brant's rocking the sexiness; the concept of validation > behaving as a try/except block feels nice to me. And bidding good-bye > to 'if errors', FormWrapper and friends will be a huge win. > > The exact details could use a little fine-tuning, though; a couple > things in particular jump out at me: > > 1. I'm not sure I like the idea of manipulators having a 'process' > method which does everything; it would feel more natural to just try > 'manipulator.save()', have that save if all is well, and catch any > validation errors. > > 2. Since we're already striving hard to get rid of 'get_absolute_url' > I'm not sure how I feel about introducing a 'get_update_url'. > > 3. Doing 'manipulator.process(request)' is probably unacceptable, > since there are tons of common use cases where you'll want to fiddle > with the soon-to-be-validated data before you let the manipulator get > involved. I can live with 'new_data' in this case. Some comments: 1: hardwired to HTML [[[ def process(self, request): "Perform the manipulation process." if (not request.POST): raise self.form self.request = request self.data = copy_dict(request.POST) ]]] I gather this proposal means validation will be highly optimised for web forms and available only on POST? I understand that is the mainline use case, but I have a preference something that wasn't baked into HTML 'cos I'll have to hack around it eventually or use something else. Can I suggest one of the following. Set up a Manipulator family and extract the prep work to a method in process() so other cases can be supported (even if it's just unit testing the validations). Or, leave the validation framework as specced but tie it right into form handling so there's room for non-form validations work on models. 2: fast fail Throwing exceptions means the first error will exit the chain. A lot of work I do involves gathering as many errors as possible. 3: exception based flow This will be my inner Java guy no doubt, but using exceptions to manage mainline execution seems wrong to me. I guess I see validation failure as not being exceptional behaviour. But as it goes, I think what's there is about as elegant as you make it with exceptions. Partially related to 2 because when you walk away from exceptions as a mechanism you are left with a chaining/pipelining approach, which will support error collation naturally. cheers Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
On 8/24/06, Bill de hÓra <[EMAIL PROTECTED]> wrote: > > I gather this proposal means validation will be highly optimised for web > forms and available only on POST? I understand that is the mainline use > case, but I have a preference something that wasn't baked into HTML 'cos > I'll have to hack around it eventually or use something else. > Well according to my original proposal, there would be a Manipulator and a GETManipulator, or a JSONManipulator. It would be easy to make as many as you'd like, just change that process function. > 2: fast fail > > Throwing exceptions means the first error will exit the chain. A lot of > work I do involves gathering as many errors as possible. > No, the Form is only thrown after each one of the three steps (converting data, validating field data, validating model data), if needed. I agree, gather as many errors as possible. > 3: exception based flow > > This will be my inner Java guy no doubt, but using exceptions to manage > mainline execution seems wrong to me. I guess I see validation failure > as not being exceptional behaviour. But as it goes, I think what's there > is about as elegant as you make it with exceptions. Partially related > to 2 because when you walk away from exceptions as a mechanism you are > left with a chaining/pipelining approach, which will support error > collation naturally. > The whole raising a Form thing is just a shocking idea. Like gabor mentioned, it's actually done often in Python. Exceptions are just a different and handy control structure to me; I understand that it's a weird idea, I just don't understand why. Anyhow, ValidationErrors are exceptions now anway, so this, in general, would actually be lessoning the ammount of Exceptions being thrown. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Extending the Site object
There has been lots of talk about extending the User object with the AUTH_PROFILE_MODULE setting. That, along with a multi-site app I am working on has lead me to wonder, What about extending the Site object with a SITE_PROFILE_MODEL setting. I guess you could accomplish the same thing with custom settings and modify them for each site, but it would be nice to use the admin app for that. What do 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Graham Dumpleton about mod_python
Bjørn Stabell wrote: > I do remember posting a comment on the Django docs site about > mod_python and mpm-worker crashes a while ago, but I cannot find it on > the Django site anymore. > > In any case, we were using mod_python 3.1.3-3. I'm happy to hear it's > been fixed in 3.2.8. Unfortunately, even Debian unstable is still at > 3.2.7, so I think a warning about this is necessary. The fixes to mod_python I spoke of are actually also in 3.2.7. Version 3.2.7 of mod_python existed for such a short time and was immediately replaced with 3.2.8 due to a potential security issue with a new feature in 3.2.7 so we tend to just ignore it and always suggest people use 3.2.8 at least. Since then mod_python 3.2.10 has been released anyway. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
