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
-~----------~----~----~----~------~----~------~--~---
