So while I would agree FormEncode has its downsides, I don't think it's
inadequate for your purposes.
No, you can't use the @validate decorator, but as has been discussed, no one
can really use it.
This is what I would recommend doing
def my_action(self):
schema = MyFormSchema()
try:
form_result = schema.to_python(request.params, c)
except formencode.Invalid:
return self._render_json({'message': 'Generic error message'})
def _render_json(response_dict):
return simplejson.dumps(response_dict)
This is only a half-baked solution, and needs to be tuned specifically for
your application, but this is a variation of what I used on my AJAX
intensive project.
Hopefully that helps
On Wed, May 12, 2010 at 6:26 AM, Haron Media <[email protected]> wrote:
>
> I'm still just learning both Python and Pylons, but it appears to me
> FormEncode is inadequate for my form needs. Seems like FormEncode was
> developed only to be used with "traditional" forms, ie. show form ->
> post data -> show back the form and error messages with HTMLFill |
> process ok.
>
> I don't want to use forms traditionally. I'm developing an application
> that has an AJAX interface, meaning forms are used only to edit or input
> new data, and the data is sent to the server via XHR. This also means
> that form processing controller responds with JSON or plaintext.
>
> And with that I have the following problems:
>
> - error message types are overwhelming, I want single error message per
> field, meaning I have to set them all to same string, per field, per form.
> - error messages are automatically prepended with field var name which
> is ugly in itself, so it is meant to be parsed by HTMLFill
> - can't use @validate decorator because it returns HTML in case of errors
> - I have not yet tried the form authorization mechanism (nonce token),
> but I guess I'll have problems regenerating it and resending with JSON
> response in case of errors
> - I have lots of forms with rather nonstandard validation, meaning I
> have to write lots of custom validator classes
>
>
> The FormEncode docs are rather lacking, so I am not sure if I'm totally
> doing things wrong, or this is really just the thing with FormEncode.
>
> What I'm tempted to do is write my own form handling class, that is port
> it from my own PHP toolkit. With such a class I wouldn't be specifying
> field names and validator classes, but validating fields procedurally
> (which is a lot more flexible and does not require that much more
> writing). For example:
>
>
> class SomeController(BaseController):
>
> def form_processor(self):
> response.content_type = "text/plain"
>
> some_model = SomeModel()
>
> form = MySimpleForm()
> try:
> form.process(some_model)
> except FormAuthError:
> response.status = 403
> return "Invalid nonce token, please reload the page."
> except FormValidationError, e:
> response.status = 400
> return e.message
>
> ...
>
>
> class MySimpleForm(SimpleForm):
>
> def process(self, model):
> # The form decides whether it should authorize the nonce token
> # This can be overriden via class constructor
> if not self.authorize():
> raise FormAuthError
>
>
> self.vars['some_int_field'] = self.toInt('some_int_field')
> self.vars['some_plaintext_field'] =
> self.toStrippedString('some_plaintext_field')
> ...
>
> if not vars['some_int_field']:
> raise FormValidationError('Invalid integer field')
> if not vars['some_plaintext_field']:
> raise FormValidationError('Invalid plaintext field.')
> if vars['x'] != vars['y']:
> raise FormValidationError('Fields x and y are not the same')
> ...
>
> # The form also decides which vars to set into the given model,
> here all
> for k,v in vars:
> setattr(model, k, v)
>
>
>
> So I need your opinion. Am I completely missing the power of FormEncode,
> or should I really continue with my own form processing class? If anyone
> is interested, I can post it when finished for others to use.
>
> Also such a class can be extended to automatically take model data on
> input and have helper methods to build forms, already containing data,
> so no HTMLFill is required (which, btw, I find rather clumsy, in parsing
> HTML to change the form...). Aditionally, the SimpleForm class stores
> data in session in case of failure, and can pick it up in next request,
> so "traditional" forms can use redirect to avoid post back problem, and
> the form class with automatically figure out that it has data in the
> session, overriding any data passed from the model.
>
>
>
> Thanks,
>
>
> Vlad
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<pylons-discuss%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
>
>
--
Brian O'Connor
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
