> If you could point out a good implementation of dynamic form
> validation in a controller using TG widgets, I'd be keen to emulate
> best practice.
There are essentially three options here (some of which might not apply to
your current situation, but I list them for completeness):
- the dynamicity of the form is rather limited, it's more about e.g. one user
and multiple addresses. This kind of dynamicity is solvable pretty easy - you
need to declare formencode validation schemas that deal with this through a
ForEach-validator. With that, it's actually possible to deal with 1:n cases
without dynamically (re)generating a form
- you have one controller action that should deal with one of several
possible forms. Which is chosen is determined at runtime. Here the trick is
to declare all the forms you need explicitly. They share one hidden-field
which forms a distinction criteria. Then you can go for the normal
control-flow of TG, but instead of passing a form (or schema) as first
parameter to the @validate-decorator, you pass a callable like this:
def chose_form():
return dict(form_a=form_a,
form_b=form_b)[request.params["distinction_field"]]
This assumes that your hidden field is called "distinction_field" and it can
take the two values "form_a" and "form_b".
The request is the cherrypy-request - I'm not 100%sure about the
params-thingy, but something very close to that gives you all the passed
parameters (GET or POST)
- you have a form that's extremely dynamic and needs to be created
on-the-fly. Then I'd combine solution two with sessions - simply create the
form as TG-widgets-form (build up the fields you need, and pass them to the
Form-constructor) - and then stuff it into the session. In the callable,
simply fetch the form from the session & return it.
> > From your post I have troubles seeing what the dynamicity is you require
> > and if there isn't a better way to work with that. Maybe if you could
> > elaborate on that, we could provide better help.
> >
> > Diez
>
> I believe my form needs to be dynamic because fields may be rendered
> as select fields, hidden or text fields depending on tbe access group
> of the user.
>
> I'll give a few examples.
>
> Depending on the user or the point in the workflow, the Store may be a
> displayed with a hidden id, or it may be a select field.
> When an order is first entered there is a qty_ordered field that is
> rendered as a text input. After a user enters their order the form
> renders as all display.
> When the order is processed by the HQ, the qty_ordered field is
> rendered as a display field. An additional qty_supplied field is
> rendered as a display field.
> After the HQ processes the order, the order is then rendered as all
> display.
<snip/>
To be honest - this is still pretty confusing to me. If what you state above
is correct that your form is essentially only differing in the actual
rendering of single values (like a dropdown or free text field), I'd go with
approach two - create the form you need for each usecase, and perform dynamic
selection via a distinction field.
If you really believe that you need the fully dynamic approach (something I
personally haven't encountered yet, there was always a more pleasing
solution), then go for the last solution.
Diez
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
