Resurrecting an old thread... Let's make this happen!
Joseph (in the e-mail below) has spelled out a pretty decent plan for the new manipulator scheme. I see that we've got another proposal in Trac by Brant Harris -- http://code.djangoproject.com/ticket/2586. Let's get something decided and implemented for Django's next version; this will be one of the last big(ish) changes before 1.0. Models already have a validate() method, but it's undocumented and not all validation (for all field types) is implemented. Put succinctly, we're looking to replace the automatic AddManipulators and ChangeManipulators that Django creates for each model. We're looking for something more natural, more flexible and more sexy. Definitely more sexy. How To Be Sexy, Rule 1: The word "manipulator" has really got to go. Thoughts/comments/suggestions on Joseph's plan below, and on Brant's plan in Trac? Adrian On 3/8/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > The short version of this is really, forms and manipulators merge and > get more powerful, models grow validation. This is an attempt to > clarify and add to Adrian's previous proposal. I hope it takes care of > people's concerns. Here are some details: > > Forms and FormFields are intended to be used for web applications > only. Models do validation, so using forms isn't necessary when > manipulating data directly in python. Also, I think something similar > to this would allow for recursive forms (edit_inline behavior), but I > haven't worked out all the details. > > Models would grow a validate method and validate=True is added as an > argument to Model's save methods. Models would not do any type > coercion. (I guess they could, but I think most type coercion should > happen in the form fields, not the model fields.) > > I'm ignoring a bunch of metaclass magic that needs to go on here, but > I hope the intentions are clear. Bring on the pseudocode... > > > class Form(object): > def __init__(self, request, prefix=''): > self.request = request > # prefix corresponds to a prefix to http variable names. The prefix > # should be used to strip off the first part of the var names. > # Hopefully this will allow for recursively defined forms... in other > # words, edit_inline is available outside of the admin system. > self.prefix = prefix > # this would actually be more complicated... use prefix to get a dict > # of strings for the form fields to coerce. > self.data = request.POST.copy() > > def _get_model_obj(self): > """ > return the cached model object, or init/cache/return one. > """ > > model = property(_get_model_obj) > > def set_defaults(self): > """ > Call get_default() (hopefully passing in self.request) on each > FormField, and set the appropriate attributes on self.model. > """ > > def validate(self): > """ > Basically just return self.model.validate(). Call validate for child > forms as well. > """ > > def save(self, validate=True): > """ > Basically just call self.model.save(validate=validate) Call save for > child forms as well. > """ > > def html(self): > """ > This is really just convenience for people who are too lazy to write > real templates. Returns a very generic form redered as html. It > should probably have enough css hooks to make it workable though. It > is meant to be called in a template like {{ form.html }} > """ > > class ArticleAddForm(Form): > # author will not be editable or displayed > exclude_fields = ('author',) > extend_fields = ( > formfields.EmailField(field_name="from", is_required=True), > ) > > class ArticleChangeForm(Form): > # author will be displayed, but not editable > readonly_fields = ('author',) > > class Article(models.Models): > name = models.CharField(maxlength=100) > body = models.TextField() > author = models.AuthorField() > > class Meta: > # this gets used in generic create views > add_form = ArticleAddForm > > class Admin: > # this gets used in the admin system > change_form = ArticleChangeForm > > > # Usage: > def myview(request): > add_form = Article.AddForm(request) > errors = add_form.validate() > if not errors: > add_form.save(validate=False) > return HttpResponseRedirect('the_next_page') > ctx = RequestContext({'form': add_form}) > return render_to_response('template', ctx) > > > I hope something like this will come out of Adrian's validation aware > model proposal. This would solve those issues, and add a ton of > flexibility to Django. There are many details that need to be pinned > down, but I think something like this should be workable. > > Also, there are things that I've probably overlooked. What are they? > > Joseph > > > > -- Adrian Holovaty holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
