On Sep 12, 2006, at 2:35 PM, Adrian Holovaty wrote:
> I've put together the beginnings of the manipulator framework
> replacement, using ideas from the various proposals we've had, plus
> inspiration from some prior art (the previous Django form/manipulator
> system, plus some ideas from FormEncod
Jacob Kaplan-Moss wrote:
> Out of curiosity, did you consider having a single ``Form`` object
> that may be bound or unbound? It seems like most of ``BoundForm``
> simply delegates down to the enclosed ``Form``, so perhaps ``Form.bind
> ()`` should store the data internally and just behave di
Adrian Holovaty wrote:
> The template would look like this:
>
>
> {% if form.sendername.errors %}{{ form.sendername.errors.as_ul }}{% endif
> %}
> Your name: {{ form.sendername.as_text }}
Does this 'as_text' mean that template will be the only place where an
actual form control
it looks good Adrian.
the only thing I could complain about it is not having a way to
replace the HTML input fields with something in the form itself.
eg.. I might want to use dojo's textedit stuff (which has custom html
it needs to generate) instead of a regular textfield.
also.. it would b
I've been working on the same thing, but my ideas differ slightly from
Adrian's. In a lot of way we're on the same page though, so that much
is encouraging :) I've liberally stolen ideas from both FormEncode and
a version of Zope 3's formlib.
There are four main classes the mostly correspond to A
On 9/12/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Out of curiosity, did you consider having a single ``Form`` object
> that may be bound or unbound? It seems like most of ``BoundForm``
> simply delegates down to the enclosed ``Form``, so perhaps ``Form.bind
> ()`` should store the data in
I agree with some opions of Joseph Kocherhans:
1) The form name should be more clearly, Joseph named it Fields, maybe
I named it DataSet
2) There should be some validator that is not tied to a particular
field, how to include them and how to show the errors
3) 3 types of validation exceptions(don
> class Form(object):
> fields = {} # This gets filled with field names and data types.
> def bind(self, **kwargs):
> "Returns a BoundForm instance for the given kwargs."
> return BoundForm(self, kwargs)
What's the rationale for using **kwargs instead of a single data
para
On 9/12/06, JP <[EMAIL PROTECTED]> wrote:
> > class Form(object):
> > fields = {} # This gets filled with field names and data types.
> > def bind(self, **kwargs):
> > "Returns a BoundForm instance for the given kwargs."
> > return BoundForm(self, kwargs)
>
> What's the rat
On 9/12/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Out of curiosity, did you consider having a single ``Form`` object
> that may be bound or unbound? It seems like most of ``BoundForm``
> simply delegates down to the enclosed ``Form``, so perhaps ``Form.bind
> ()`` should store the data in
Hi Adrian
On the whole, this looks like pretty good stuff to me. A few comments
along the way; some of these ideas need not be in the v1
implementation, but I mention them anyway so that we don't roll out a
system that can't accomodate them in the future:
On 9/13/06, Adrian Holovaty <[EMAIL PROT
Adrian Holovaty wrote:
> Similarly, how would is_valid() and errors() work? If is_valid() or
> errors() get passed kwargs, does the form instance automatically
> become a BoundForm? What if it's already been bound? Do the kwargs
> replace any existing bound data?
I think with just one Form class
Russell Keith-Magee wrote:
> +1 to providing the ability to select a widget at the template level,
> but -1 to requiring .as_text for the default case.
What if widgets could act as filters? I think using filter syntax for
setting the widget for a field in the template would be pretty
natural::
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
Joseph Kocherhans wrote:
>
> form = ContactForm()
> if request.method == POST and form.bind(request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':form})
>
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the
JP wrote:
> What if widgets could act as filters? I think using filter syntax for
> setting the widget for a field in the template would be pretty
> natural::
>
> {{ form.field }}
>
> draws the default widget for the field type, but if you want to use
> SomeOtherWidget, you can do::
>
> {{ fo
Joseph Kocherhans wrote:
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the validation and probably populates form.errors or .errors() or
> whatever. bind returns True or False depending on whether validation
> succeeded or not. bind does not short circuit on the first e
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
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
Brantley Harris wrote:
> > 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
+1
Being able to contruct fields dynamically would be great.
On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> > 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
On Tue, 2006-09-12 at 14:35 -0500, Adrian Holovaty wrote:
> The template would look like this:
>
>
> {% if form.sendername.errors
> %}{{ form.sendername.errors.as_ul }}{% endif %}
> Your name: {{ form.sendername.as_text }}
>
> {% if form.senderemail.errors %}{{ form.senderemail.
On 9/13/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> > > For instance, using the given example:
> > >message = TextField(label='Your message',
> > > attributes=
On Tue, Sep 12, 2006 at 02:35:54PM -0500, Adrian Holovaty wrote:
> 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()
I'd like to see some flexibility to output HTML4 as opposed to XHTML
(or whatever flavor comes along next).
Currently in 0.95 it looks like all the render() calls on the various
"generic widgets" output XHTML form elements. I've been pretty much
convinced not to use XHTML by Ian Hickson (at leas
I'm sorry to say that I missed the thread "Proposal: Forms and
BoundForms" last month. I'm very interested in the topic, largely
because, having run out of patience with manipulators, I had written
code to handle form definition, validation, and rendering that is
similar to the proposals describe
On 9/13/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Joseph Kocherhans wrote:
> > Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> > the validation and probably populates form.errors or .errors() or
> > whatever. bind returns True or False depending on whether validation
On 9/13/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> (I'm not an official "dev" so I hope it's not considered inappropriate
> of me to provide my feedback.)
It's not inappropriate at all. :)
> Instead of the assumption that bind() validates, why not have an
> is_valid() method that assumes bind
On 9/15/06, Scott Paul Robertson <[EMAIL PROTECTED]> wrote:
> Inter-field dependency. For example:
Most of this looks like it can be much more flexibly handled by the
already-available validator syntax (which, I assume, will be finishing
its migration into the model system).
--
"May the forces
On Fri, Sep 15, 2006 at 09:25:37PM -0500, James Bennett wrote:
>
> On 9/15/06, Scott Paul Robertson <[EMAIL PROTECTED]> wrote:
> > Inter-field dependency. For example:
>
> Most of this looks like it can be much more flexibly handled by the
> already-available validator syntax (which, I assume, wi
On 9/18/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Of course, all this is based on my assumption that something like this:
>
>
>
> is invalid as HTML4, but I haven't verified that HTML4 can't have self
> closing tags.
It's valid, but it doesn't mean the same thing it does in XHTML; in
HTM
On 9/18/06, James Bennett <[EMAIL PROTECTED]> wrote:
> greater-than sign (SHORTTAG NET, the particular flavor of SHORTTAG in
> this example, dictates that a single forward slash constitutes the
> closing of the element
I mistyped that and sent too soon; the slash actually closes the tag,
not th
32 matches
Mail list logo
