Using Django Forms with Pylons (and a successor to @validate?)
Marcus Cavanaugh
change so far. I've posted a writeup, and a drop-in module, on using
django.forms with Pylons here:
http://marcuscavanaugh.com/posts/pylons-django-forms/
Also, if django.forms isn't your thing but you still want to use
FormEncode, I included some code that lets you use FormEncode
validation with django-style controller code (to replace @validate).
I've thought about @validate for a long time now, and I don't think a
decorator will ever give the flexibility we need; Django's idioms work
equally well for FormEncode, so maybe that will spark your interest.
YMMV, of course, but I'm using Django's Forms with my project now and
I'm very happy with it.
Matt Feifarek
I've switched to using django.forms with Pylons, and I really like the
change so far. I've posted a writeup, and a drop-in module, on using
django.forms with Pylons here:
Every now and then a little flare-up of anxiety has hit me about the attempt you and I did at PyCon... and each time I didn't know what to do to "fix" @validate or to make recommendations based on what you and I worked through.
Thanks for sharing your solution. I expect that ditching @validate is the right way to fix @validate.
Mike Orr
That's an idea. We could just split the validator code into parts and
then not bother reassembling the decorator.
I'm of mixed minds on Marcus' approach. People have been using
django.forms with Pylons for quite a while. And I always used to do
form presentation-validation-action all in one method before I came to
Pylons. I never did quite accept the argument for splitting them into
separate methods, except that it avoids a complex if-block, for
whatever that's worth.
But I don't know if Pylons is ready for such a major change when we're
trying to nail it down for 1.0. A FormEncode wrapper might be
worthwhile, though I'm not sure it's buying you much if DjangoForms
compatibility is not a constraint. FormEncode schemas are already
complicated enough, so I'm a bit uneasy about combining them with a
form and wrapper code in the same class. I'd be more comfortable with
a wrapper that contains a schema rather than being a schema.
The one-method system would also break for resource routes, where
unrelated actions are doubled up on the same URL. I suppose with
POST/PUT/DELETE conditions, Routes could route to the same action for
edit/update and new/create. But it would probably have to be a
separate method (.resource2) given the significant difference in
behavior.
--
Mike Orr <slugg...@gmail.com>
Dan
It uses the same pattern as Django forms, and might be a bit further
developed.
On Oct 2, 10:17 pm, Mike Orr <sluggos...@gmail.com> wrote:
Marcus Cavanaugh
> WTForms does this already:http://wtforms.simplecodes.com/
>
> It uses the same pattern as Django forms, and might be a bit further
> developed.
that's a win-win.
Mike Orr
>
> WTForms does this already: http://wtforms.simplecodes.com/
>
> It uses the same pattern as Django forms, and might be a bit further
> developed.
That looks pretty elegant. It would obviate FormEncode, htmlfill, and
the form helpers, it looks like. Are the validators complete? Not
that FormEncode's validators are easy to use in their semi-documented
state.
Can you use the validators alone without the form? I use a FormEncode
schema to validate the INI file in environment.py, so that I can make
all exceptions happen at the beginning rather than in unexpected
requests.
If you can make a Pylons tutorial for it, we can consider documenting
it in the next version of Pylons.
--
Mike Orr <slugg...@gmail.com>
Dan
dates, etc. However writing custom validators is very simple (compared
to FormEncode) and it should be easy to "fill in the gaps" with
additional validators, which could be added to the Pylons core or
submitted to WTForms.
On Oct 3, 5:23 am, Mike Orr <sluggos...@gmail.com> wrote:
DavidG
FormEncode? I find this a very useful feature.
Both solutions look really nice - I wonder what the advantages/
disadvantages to using WTForms are, compared to FormEncode/htmlfill? I
never had much luck with @validate, so handling the details of form
logic has always been a bear with the current patterns.
David
Kevin J. Smith
Cheers
--
Never take life seriously. Nobody gets out alive anyway.
Mike Orr
>
> Does either Django forms or WTForms support chained validators a la
> FormEncode? I find this a very useful feature.
You can have a list of validators per field. I'm not sure if you can
have a list of post-validators for the form, but there are methods you
can override to customize form validation , which I think would give
you the equivalent.
> Both solutions look really nice - I wonder what the advantages/
> disadvantages to using WTForms are, compared to FormEncode/htmlfill? I
> never had much luck with @validate, so handling the details of form
> logic has always been a bear with the current patterns.
It looks like WTForms is adequate for everyday use but it has some
missing features for advanced situations. One is a "ForEach" construct
for repeatable groups of fields. Another is field names that aren't
valid Python identifiers. (formencode.schema has a 'fields' dict for
these.)
It definitely has a learning curve because the way you build forms is
different, the validator syntax is different, and the way you nest
group fields is different. But it looks simpler than ToscaWidgets.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
> I am not so sure why everyone seems to be so unhappy with FormEncode. I
> find it a rather brilliant solution. There is definitely a steeper than
> average learning curve but like all things that are powerful and can be
> adapted to any situation, there is always a tradeoff. I would hate to see
> support for FormEncode lost in Pylons. I currently use @validate with
> custom validators and formatters with htmlfill with great success. I think
> it would be a great loss to move to some simpler solution that is not as
> powerful. The reason I chose Pylons is for its power to adapt, otherwise, I
> would have gone with Django - less learning curve but less adaptable. If
> there is going to be support added for an alternative form processing
> framework on top of FormEncode then that is great but I would hate to see
> FormEncode dropped. I know that I could always continue using FormEncode
> because Pylons is flexible but maintaining @validate on my own is not the
> ultimate situation.
It's too late to drop FormEncode, htmlfill, and the form helpers.
We've been promising people for months that the biggest changes in
Pylons have already been done. It's one thing to drop a bad set of
helpers (the rails helpers, buggy and unmaintainable). It's another
thing to completely change the form+validation API. FormEncode
works; it's just under-documented and the code contains dead-end cruft
(i.e., useless validators). I'm just thinking that if Pylons were
being created now, WTForms might have been a better approach, and Ian
might not have written FormEncode in the first place.
The developers have still not evaluated WTForms. I only found out
about it Friday, and I haven't tried using it in an application yet.
I'm just saying that if it proves successful, it may change future
documentation and development. I.e., mention it in the manual as an
alternative to FormEncode, and perhaps even have a tutorial for it.
The plans to update @validate and write another FormEncode manual may
be canceled. I doubt Pylons' dependencies will change. It would be
silly to depend on two form libraries, and we can't drop
FormEncode/WebHelpers because they've been promised as a part of
Pylons. If you don't use them, they're a small amount of pure-Python
code to carry around.
If you want to take on the @validate updating, that might be possible.
The tentative plans are in the ticket. You'd just have to keep it
backward compatible or change the name.
http://pylonshq.com/project/pylonshq/ticket/405
--
Mike Orr <slugg...@gmail.com>
Dan
very familiar with FormEncode, so perhaps not):
http://wtforms.simplecodes.com/docs/fields.html#field-enclosures
Ian Bicking
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker