On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote: > > On 9/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > Hence, with this new API, the above view code would be written like this: > > > > form = ContactForm() > > if request.method == 'POST' and form.is_valid(**request.POST): > > send_email_and_redirect() > > return render_to_response('email_form.html', {'form': > > form.bind(**request.POST)}) > > > > "send_email_and_redirect()" > I want that function. Surely, this is a basic example, but it hides some of > the other issues that need to be hammered out. How do you access the > data once it's validated? How do validation aware models interact > with this BoundForm? Does the user have to set up a try, except block > when they save an object or does the form know something about the > model that allows it to validate it with the validation aware model? > Finally, how does one set the default data? > > > The template would look like this: > > > > <form action="/foo/" method="post"> ... > > Personally I think it should be like this: > <form action="/foo/" method="post"> > {% render-form form %} > </form> > > That should give you almost exactly what the Admin does. If you want > more control, then you should be able to, but for the most simple > case, this should be possible. > > > 1. form.sendername.errors.as_url rather than > > form.sendername.html_error_list. This gives us some flexibility to add > > other error shortcut-display types, like JavaScript or something. > > Don't we have template tags for this sort of stuff? I favor a > "to_html" for just about everything in the common case, including > error lists. Otherwise, a filter or template tag should be used, or > the object's class could be subclassed do define other functionality. > (Come to think of it: the template rendering should check for a > "to_html" or ''__html__'' function before it tries str() when it comes > across "{{ object }}") > > > Let's change this to be similar to model classes, like so: > > > > class ContactForm(Form): > > sendername = TextField() > > senderemail = EmailField() > > subject = TextField(maxlength=20, blank=True) > > message = TextField() > > > > +1 > > I also think some extra default kwargs should be available: > attributes = <dictionary of attributes to add to (or overwrite) on > the rendererd tag> > label = <the label for the rendering mechanism> > > For instance, using the given example: > message = TextField(label='Your message', > attributes={'class':'vRichTextField'}) >
+1 on this for me. I'd love to be able to do: author = SelectField(attributes={'dojoType': 'Select'}) > > One big change, other than the syntax, is that 'is_required' is > > dropped, in favor of 'blank', to match our model syntax. Also, as in > > models, blank=False will be default. Currently in manipulators, > > is_required=False is default. > > This is backwards to me. "is_required" is much more descriptive; > "blank" seems to say "this field is blank". I agree that it should > match up with the model, but I posit that the model syntax should > change. New users constantly ask about this in the chat-room; they > don't see a difference between "blank" and "null" in the model syntax. > I prefer "required", which is easier to understand, and is part of > the common web parlance: "required fields are marked in red". I don't > care whether it's default or not, although I would suggest polling > many real-world cases to find the most common option. > > > > > Another big change is that each of the Fields in this ContactForm > > would be responsible primarily for *validation* rather than specifying > > the HTML form field. This decouples the concept of validation from the > > HTML form type. > > > > I don't understand this, and I think might hold the key to a greater > understanding of your plans, could you explain how validation would > work exactly? Also, I agree with limodou that there should be a > general "validate" function that allows the writer of the Form to > provide some custom validation on the form as a whole. Likewise there > should be a "convert" function that does the same but for conversion > from HTML-POST data to Python data. > > > Another thing to note: In the current Manipulator framework, sometimes > > it is convenient to be able to construct self.fields dynamically. We > > should provide a way to do that with the new syntax. > > +1 > > > So that's the proposal -- thoughts/criticisms? I'd like to get this > > out there as soon as possible, because we (or, rather, I) have dawdled > > for quite some time! > > Some things occur to me: > > The whole BoundForm and Form thing is really crufty. When does the > Form NOT have data associated with it? And when would you really want > to have it validate data but not "bind" that data? > > There needs to be a fundemental change in the model syntax as well, > which I'm sure you don't want to hear, but it's true. Half > (hyperbolishly) of the stuff that is in the model syntax is really > there to define the Form. You have this sort of siamease twin, but > I'm not sure if it should be ripped apart or reinforced to support the > whole DRY / in-one-place paradigm. > > Defining a Form, should be like defining a Model-Manager, it should be > portable in the way that many applications can utilize it, including > the one the Model was written for AND the Admin. That is why I favor > a "Manipulator" approach which would not only define fields, but also > define what to do with the resulting data. > > Idealy, it sems to me, every part of the Admin should be reusable in > our applications. It would be a great step in this direction if forms > could be rendered very easily as in: {% render-form form %} > > Thanks > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---