how can I cause a form error outside of an @validate schema ?
Jonathan Vanasco
i have the validator handling stuff fine, however in some situations i
need to cause an error within the controller.
currently this just republishes the form; I need to figure out how to
get the form show the correct and incorrect values
d2ncal
Currently, I am setting session['flash_error'] and calling my
show_form function which does htmlfill. but there has to have a better
way.
Jonathan Vanasco
> I am looking for the same thing.
>
> Currently, I am setting session['flash_error'] and calling my
> show_form function which does htmlfill. but there has to have a better
> way.
Mike Orr
>
> where does webhelpers get the data for form values ?
>
> i have the validator handling stuff fine, however in some situations i
> need to cause an error within the controller.
This is one of the problems with @validate; it's not flexible enough
for this situation. The developers are mulling over ways to rewrite
it or replace it.
You can generally do what @validate does:
html = self.my_form_method()
return htmlfill.render(html, request.params, {"error_field": "Error
Message"}) # Or request.POST for post-only situation
--
Mike Orr <slugg...@gmail.com>
Thomas G. Willis
If you need to validate the entire form, use a chained validator(or
several), In your validator you can make your error message say
whatever you want.
Spend some time with the docs, they are pretty thorough. http://formencode.org/
and maybe consider not using the validate decorator, not because it
doesn't work or is not useful, but it is a tad less flexible, and I
don't think it saves you very much honestly.
Also, when I was trying to get my brain comprehending this stuff, this
section of the pylons book was invaluable. A true "A-HAH !!!!!!"
moment honestly.
http://pylonsbook.com/en/1.1/working-with-forms-and-validators.html#handling-forms-manually
Thomas G. Willis
> This is one of the problems with @validate; it's not flexible enough
> for this situation. The developers are mulling over ways to rewrite
> it or replace it.
>
> Mike Orr <sluggos...@gmail.com>
What's been discussed so far? I've been thinking about this a lot
lately because validation is tedious(obviously) but I have yet to find
a less tedious solution. I'd be interested in hearing what the smart
guys are kicking around though.
Jonathan Vanasco
of things I don't like about it.
Chained Validators are not an option for me, and likely others. They
work great for validating the input, but in many cases you have
business logic within the controller that can then invalidate the
process. It's sad that in Pylons the options are only to put
controller logic in a validator, or devise some way to otherwise
emulate a form error.
I may just write my own @validate routine , and tie it to helper
functions that can be called independently to handle populating the
errors and displaying them.
Mike Orr
>
> I would think formencode/htmlfill allows for this.
>
> If you need to validate the entire form, use a chained validator(or
> several), In your validator you can make your error message say
> whatever you want.
This is generally true, but sometimes you need to flag an error based
on information outside the form data, or not known until a particular
point in the action. This is generally related to other data in the
database or in the session.
You can pass it to the validator via the 'state' argument, but there
are three problems with that:
- 'state' is incompatible with @validate because the state is not
known when the decorator is called.
- Checking external conditions can make the validators ugly and
non-portable.
- 'state' is not well thought through. The docs give the
impression that you can pass anything, but I think parts of FormEncode
assume it's a dict and add keys if so?
If you don't use 'state', your other choice is to check it manually in
the action.
--
Mike Orr <slugg...@gmail.com>
D D
if not values:
Mike Orr
Originally there was a plan to split it into three parts, with
@validate calling the parts in order for compatibility.
http://pylonshq.com/project/pylonshq/ticket/405
Since then, there has been discussion about just leaving the decorator
as-is and writing some utility functions for the controller, or
promoting WTForms (http://wtforms.simplecodes.com/), or adding more
support for one-method form handling (doing form & validation in the
same method).
I was initially enthusiastic about WTForms but I think it may be too
big a jump for Pylons. (That doesn't mean you can't use it, or that
it shouldn't have a Pylons Howto eventually.)
There's a lot to be said for doing the form and validation in the same
action. Something like:
if request.POST:
if not validation-errors:
do action and return success page or redirect
display form(maybe with data and errors)
I always did this until I came to Pylons. It avoids the need for a
decorator. I've been using @validate because the Pylons tradition is
to have separate methods for the form and validation, but I'm
beginning to wonder if it's worth it. I'd like to add a map.resource
method that uses one-method form handling, to make it easier to do.
--
Mike Orr <slugg...@gmail.com>
Kevin J. Smith
--
Never take life seriously. Nobody gets out alive anyway.
Mike Orr
> I'm curious as to what everyone's hate for @validate is. I have been a long
> time user of FormEncode and new to Pylons and found @validate pretty damn
> slick. I've got custom validators and chained validators and never really
> had a complaint. I've definitely ran into situations that have me
> scratching head as to how I am going to get it to work but there always
> seems to be a way and it ends up being reasonably elegant with FormEncode.
The decorator works, it's just limited. Ideally you want to do all
your validation the same way. But @validate can only handle some
cases.
1. If you want to validate based on the current database record, that
isn't known until the middle of the action. This would be a good use
for 'state', but there's no way to pass state through the decorator.
2. The default post_only=True, on_get=False is ridiculous. It ends up
passing GET requests through without validation, which will then cause
your action to crash (if expected data isn't there or is the wrong
type) or to perform an action it shouldn't.
3. If the validation passes but you later want to flag a different
error, you're in the same situation the OP is in.
4. If you want to perform some of the error handling in the action,
you can't just paste code from @validate because it does a lot of
other stuff to deal with its arguments, and you have to sit there and
think about which parts of the code are relevant to the situation and
how to transform them.
--
Mike Orr <slugg...@gmail.com>
Kevin J. Smith
Ian Wilson
I think validate was created as a simple yet incomplete solution but
people expect it to do everything. This causes confusion. Once you
have any sort of complexity you have to start doing validation
manually which is kind of OK except no one has any really good
examples and its a ton of boiler plate. I think the biggest problem
with formencode, validate and the whole paradigm of validation is that
there really is no great domain for examples to be placed in. Other
people have built up these well partitioned components(or tried to) as
Ian Bicking describes here [1] but there is no framework to really say
this is how they should/can/may fit together. And when more components
are made its not clear where they go so that other people can find
them and extend them. Its not really formencode's thing and its not
really a pylons' thing. I will mention though that I think
formencode's validators and htmlfill are part of the solution although
maybe they themselves need some improvements.
Anyways I think this can be solved with some incredibly well
documented examples and some more tools in webhelpers. The examples
should be tied to specific versions of specific libraries that
webhelpers may or may not actually depend on, like mako and pylons for
example. Sort of like a web based form processing manual but with a
name that isn't horrible. To find out what those tools are I think we
should _talk_ about the most generic framework for form validation
possible using formencode validators and htmlfill with mako and pylons
but not actually design such a framework as much as design the tools
for the framework. As it evolves we can build better examples and
better helpers.
Fitting javascript in all this is a different problem alltogether.
For example if you want to create a list of users that you can sort,
add and remove BEFORE posting to the server, how does everything fit
together? I've created code for this and its not very pretty but I
think its the right idea. Yet everytime I try to extend it I have to
review every little detail so that I don't mess it up which leads me
to believe a tool or an abstraction is missing here as well.
So some comments with regard to what I think such a virtual framework
would need to allow for:
1. the separation of form prompt(initial display), form
redisplay(errors) and form rendering(shared by initial display and
redisplay).
2. ability to remove field defaults from being redisplayed (ie. passwords)
3. A dummy state class that can be used with formencode
4. How to pass in the proper encoding, these seems to have changed
since some form examples were put in the wiki and I don't understand
why some are more complicated than others.
5. How to handle repetitions in the template, schema and error handling
6. How to handle javascript and repetitions
7. How can non-javascript be safely handled when a form is dynamically
built with javascript callbacks? For example updating a form's layout
depending on the type of user to create.
8. How to manually raise errors in such a way that the form is
redisplayed as if the FE schema didn't succeed.
9. How are options used in the form? How can the validators use these
options to validate the form? How can they be used to validate AND
redisplay the form on error without multiple db requests?
[1] http://blog.ianbicking.org/on-form-libraries.html
Sorry this email has gotten so wordy.
-Ian Wilson
Mike Orr
> Thanks for the clarification, Mike. So it is really an issue with the
> decorator rather than FormEncode as a whole, correct? As I mentioned, I
> have never ran into issues with FormEncode but I have only just started
> using Pylons therefore haven't ran across a huge number of cases with the
> decorator.
FormEncode's main problem is it needs a better manual, which I'm
working on. The examples in the manual are geared toward interactive
usage, which leaves you somewhat at a loss for how to use them in
Pylons. Which options to use for a checkbox, advanced uses, schemas,
chained validators, how the messages work -- these are all things I
had to puzzle through at various occasions.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
>
> I think validate was created as a simple yet incomplete solution but
> people expect it to do everything.
Yes. I think it was created because TurboGears had a validate
decorator and we wanted one too. It solves the use cases it was
designed for, but not the ones it wasn't. I don't know how other
frameworks, which are generally more rigid than Pylons, work around
these use cases. How do TurboGears users handle edge cases in
validation?
> I will mention though that I think
> formencode's validators and htmlfill are part of the solution although
> maybe they themselves need some improvements.
>
> Anyways I think this can be solved with some incredibly well
> documented examples and some more tools in webhelpers.
What specific improvements? Ask and ye may receive. Don't ask and
you definitely won't.
> To find out what those tools are I think we
> should _talk_ about the most generic framework for form validation
> possible using formencode validators and htmlfill with mako and pylons
> but not actually design such a framework as much as design the tools
> for the framework. As it evolves we can build better examples and
> better helpers.
Maybe. We'd need to consider a concrete example of the "tools" or
design patterns to judge their feasability.
Some people use Mako def's to layout a widget with its label and error
message and other goodies. Mako's call-with-content feature is good
for plugging some (custom) HTML inside other (boilerplate) HTML.
> So some comments with regard to what I think such a virtual framework
> would need to allow for:
These are the design patterns, I suppose?
> 1. the separation of form prompt(initial display), form
> redisplay(errors) and form rendering(shared by initial display and
> redisplay).
What would that gain you? Are you talking about something like a
class with methods for these three parts?
> 2. ability to remove field defaults from being redisplayed (ie. passwords)
This would probably have to be done at the controller level, zapping
any data values you don't want to redisplay. A form-framework class
could have a .zap-these-fields method.
> 3. A dummy state class that can be used with formencode
FormEncode's 'state' assumptions need to be documented. Ian once
remarked he wished 'state' had defaulted to something else rather than
None; I don't remember if it he'd wanted an empty dict or object.
How would a dummy state object help?
> 4. How to pass in the proper encoding, these seems to have changed
> since some form examples were put in the wiki and I don't understand
> why some are more complicated than others.
I'm not aware of any encoding changes in FormEncode, but there may
have been. There were some bugs with Routes and Unicode arguments,
but that's another thing.
> 5. How to handle repetitions in the template, schema and error handling
That's what the ForEach validator is for, but it's undocumented. I've
never gotten the hang of repeating form widgets, so I avoid them. If
somebody who understands them can write a howto for putting a
repeatable row of widgets on a form and validating them, that would be
very helpful.
> 6. How to handle javascript and repetitions
> 7. How can non-javascript be safely handled when a form is dynamically
> built with javascript callbacks? For example updating a form's layout
> depending on the type of user to create.
My understanding of Javascript is basic so I'll skip these.
> 8. How to manually raise errors in such a way that the form is
> redisplayed as if the FE schema didn't succeed.
This needs to be documented in any case.
> 9. How are options used in the form? How can the validators use these
> options to validate the form? How can they be used to validate AND
> redisplay the form on error without multiple db requests?
What kind of "options" do you mean? There are SELECT options,
validator constructor args, etc.
--
Mike Orr <slugg...@gmail.com>
Ian Wilson
> On Fri, Oct 23, 2009 at 4:44 PM, Ian Wilson <vengfulsquir...@gmail.com> wrote:
>
> > I think validate was created as a simple yet incomplete solution but
> > people expect it to do everything.
>
> Yes. I think it was created because TurboGears had a validate
> decorator and we wanted one too. It solves the use cases it was
> designed for, but not the ones it wasn't. I don't know how other
> frameworks, which are generally more rigid than Pylons, work around
> these use cases. How do TurboGears users handle edge cases in
> validation?
>
> > I will mention though that I think
> > formencode's validators and htmlfill are part of the solution although
> > maybe they themselves need some improvements.
>
> > Anyways I think this can be solved with some incredibly well
> > documented examples and some more tools in webhelpers.
>
> What specific improvements? Ask and ye may receive. Don't ask and
> you definitely won't.
I saw your mail on the FE list and I made some changes to the wiki
document. I might make some more.
>
> > To find out what those tools are I think we
> > should _talk_ about the most generic framework for form validation
> > possible using formencode validators and htmlfill with mako and pylons
> > but not actually design such a framework as much as design the tools
> > for the framework. As it evolves we can build better examples and
> > better helpers.
>
> Maybe. We'd need to consider a concrete example of the "tools" or
> design patterns to judge their feasability.
I made an example linked below [2], but its still pretty ugly. I
guess that's actually the point, how can we hide the ugliness in such
a way that its easy to do simple form validation and moderately easy
to extend it to do more complicated validation(repetitions, use of
state, etc). I don't think decorators really work because there are
two many intermediary steps that need hooks not just one step in the
middle. I don't really feel like the clunker of a class I just made
is a solution but at least its an example of the steps necessary to
provide validation. Maybe some people have suggestions on how to
handle this or see functionality that can be encapsulated in a tool.
Other people might think that all this is not worth encapsulating and
everyone should just write it themselves from scratch, I think we can
do a smidgen better than that though.
>
> Some people use Mako def's to layout a widget with its label and error
> message and other goodies. Mako's call-with-content feature is good
> for plugging some (custom) HTML inside other (boilerplate) HTML.
Yes and that is how it should be, everyone does markup their own way,
EXCEPT it makes documentating a generalized example of using all the
data pieces a pain.
>
> > So some comments with regard to what I think such a virtual framework
> > would need to allow for:
>
> These are the design patterns, I suppose?
They are more like edge cases to the form processing design pattern,
if you want to call it that.
>
> > 1. the separation of form prompt(initial display), form
> > redisplay(errors) and form rendering(shared by initial display and
> > redisplay).
>
> What would that gain you? Are you talking about something like a
> class with methods for these three parts?
Yeah I've included such a class. You can seperate GET and POST
between the prompt and process methods for one thing and you don't
have to check if the form should be received or sent. Also it will
compress down to the less general case where both actions are the same
action.
>
> > 2. ability to remove field defaults from being redisplayed (ie. passwords)
>
> This would probably have to be done at the controller level, zapping
> any data values you don't want to redisplay. A form-framework class
> could have a .zap-these-fields method.
Yeah I think this should be custom but it has to kind of sit between
everything else so it needs a hook or something. In the example given
you could strip it from defaults in your own version of
_process_error().
>
> > 3. A dummy state class that can be used with formencode
>
> FormEncode's 'state' assumptions need to be documented. Ian once
> remarked he wished 'state' had defaulted to something else rather than
> None; I don't remember if it he'd wanted an empty dict or object.
>
> How would a dummy state object help?
As far as I know formencode will not work unless you pass an object as
the state, ie. it will not take a dictionary. Therefore everytime you
need state you make a class, any class. Its just two lines to have it
do nothing but its two lines I have to write _every_ time I want a
state object. If you want it to repr/str to something useful you have
to add that everytime as well. This is the kind of boiler plate that
by itself is nothing but summing up becomes annoying. Is there a
Dummy class in the python stdlib? We chould probably do something
more creative with its contructor than nothing though. There are
examples in the wiki.
>
> > 4. How to pass in the proper encoding, these seems to have changed
> > since some form examples were put in the wiki and I don't understand
> > why some are more complicated than others.
>
> I'm not aware of any encoding changes in FormEncode, but there may
> have been. There were some bugs with Routes and Unicode arguments,
> but that's another thing.
Actually you are right I don't think anything changed, I meant in
pylons though.
Something like the madness(I'm sure its fine I just don't see why)
seen here has to be used: [1].
>
> > 5. How to handle repetitions in the template, schema and error handling
>
> That's what the ForEach validator is for, but it's undocumented. I've
> never gotten the hang of repeating form widgets, so I avoid them. If
> somebody who understands them can write a howto for putting a
> repeatable row of widgets on a form and validating them, that would be
> very helpful.
>
Yes ForEach is just the start though, NestedVariables + pulling
repetitions from the values after encoding them gets really wild.
Especially if you have nested things and want labels with valid ids.
> > 6. How to handle javascript and repetitions
> > 7. How can non-javascript be safely handled when a form is dynamically
> > built with javascript callbacks? For example updating a form's layout
> > depending on the type of user to create.
>
> My understanding of Javascript is basic so I'll skip these.
Yeah eventually we aren't going to be able to get away with ignoring
javascript's role in form processing.
>
> > 8. How to manually raise errors in such a way that the form is
> > redisplayed as if the FE schema didn't succeed.
>
> This needs to be documented in any case.
>
> > 9. How are options used in the form? How can the validators use these
> > options to validate the form? How can they be used to validate AND
> > redisplay the form on error without multiple db requests?
>
> What kind of "options" do you mean? There are SELECT options,
> validator constructor args, etc.
Yeah I meant more of options for selects, but really any dynamic data
that is needed during form validation AND presentation.
>
> --
> Mike Orr <sluggos...@gmail.com>
[1] https://www.knowledgetap.com/hg/pylons-dev/file/5b3367b3aac1/pylons/decorators/__init__.py#l175
[2]
(template)
http://pylonshq.com/pasties/e881e31a8fb3801cecd5d849c98e9247
(usage)
http://pylonshq.com/pasties/728ebeea0a28d21df6c76af72a07c365
(library outlining hooks and core functionality)
http://pylonshq.com/pasties/92435103c1ab8ae05b5705cb641ae7d0
-Ian Wilson
Mike Orr
>
>> > 1. the separation of form prompt(initial display), form
>> > redisplay(errors) and form rendering(shared by initial display and
>> > redisplay).
>>
>> What would that gain you? Are you talking about something like a
>> class with methods for these three parts?
>
> Yeah I've included such a class. You can seperate GET and POST
> between the prompt and process methods for one thing and you don't
> have to check if the form should be received or sent. Also it will
> compress down to the less general case where both actions are the same
> action.
Base controllers like your #2 and #3 links are a good idea. Put them
in the Pylons Cookbook and if any of them get highly used, they might
be considered for the Python core.
>> > 3. A dummy state class that can be used with formencode
>>
>> FormEncode's 'state' assumptions need to be documented. Ian once
>> remarked he wished 'state' had defaulted to something else rather than
>> None; I don't remember if it he'd wanted an empty dict or object.
>>
>> How would a dummy state object help?
>
> As far as I know formencode will not work unless you pass an object as
> the state, ie. it will not take a dictionary. Therefore everytime you
> need state you make a class, any class. Its just two lines to have it
> do nothing but its two lines I have to write _every_ time I want a
> state object. If you want it to repr/str to something useful you have
> to add that everytime as well. This is the kind of boiler plate that
> by itself is nothing but summing up becomes annoying. Is there a
> Dummy class in the python stdlib?
``webhelpers.containers.DumbObject``
It creates attributes for its keyword args. It doesn't do anything else.
There's also ``formencode.declarative.Declarative``, which uses
metaclass tricks to set up standard attributes from positional args.
The closest thing in the stdlib is ``object``, but you can't use it
for data because its instances won't take attributes.
--
Mike Orr <slugg...@gmail.com>
Ian Wilson
I ended up using the containers class you mentioned. I think my
solution is _really_ similar to Tycon's solution as mentioned in the
splitting validate ticket except I don't use decorators. Somehow I
did not see his solution until I saw that ticket
(http://pylonshq.com/project/pylonshq/ticket/405).
First off a couple of things. Some weirdo stuff that is in validate
should probably be in here, something like merging str/unicode params
and str/unicode forms etc. Or maybe not, a bunch of stuff in validate
I think should just stay in validate but I'm no library writer. I've
been using this code inside a project for a month now and its been
going pretty well although it has all been for an unreleased project.
Also I do not vouch for the actual login code at all I just made it up
for this example. I'll try to add some more robust examples in the
next month. Anyways check it out and tell me what you think:
Usage:
http://bitbucket.org/ianjosephwilson/pylonsformer/src/tip/pylonsformer/controllers/login.py
http://bitbucket.org/ianjosephwilson/pylonsformer/src/tip/pylonsformer/templates/login.mako
Major parts of the form handling library that uses formencode and
webhelpers(barely):
http://bitbucket.org/ianjosephwilson/former/src/tip/former/handler.py
http://bitbucket.org/ianjosephwilson/former/src/tip/former/pylonshandler.py
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>