Multipage Form construction
cd34
than a long form. Each page would have separate validation, but, the
data shouldn't be submitted until the end.
I can think of a few methods to do it that are simplistic that
maintain validation -- passing the prior page form values as hidden
fields maintaining the validation so that the data cannot be easily
altered from one page to the next, but, is there a method within
ToscaWidgets to automatically handle multipage forms?
Diez B. Roggisch
No, there isn't specific support. What I would do is this:
- don't use validators for formfields, instead use Schemas
- try combining schemas - I'm not sure if that's inherently supported
in formencode, but it shouldn't be hard to write it anyway (I've done
that once before, bot don't have the code handy)
I'm not sure if there is a way to declare the formfields automatically
as HiddenInputfields, but you might consider writing a helper-function
for that as well.
All in all, it would be a worthy extension to TW-forms.
Diez
Paul Johnston
> I'm working on a project where a multipage form would be much easier
> than a long form. Each page would have separate validation, but, the
> data shouldn't be submitted until the end.
TW doesn't have anything specifc. You could use something like the
tabber in tw.yui, and put the field on different tabs.
If you have any suggestions for how the widget library could further
help with this, let us know.
Paul
cd34
probably would work pretty well, however, it isn't a generic solution
and would be rather complex to deploy on more than a one-off solution.
What I thought about was doing something along the lines of TableForm,
but call it MultiPageForm. Each Widget in the widgetlist would have
an additional parameter of the page number. The template and
rendering would then determine which widgets to display based on the
active page number. With the use of hidden fields could determine
what validation would need to be performed on each step, and would
allow forward/backward navigation of the form.
Sort of a TableForm/ListForm with pagination.
At this point, I'm not familiar enough with the internals (as you saw
in my other post), but, I do need this capability and will probably
have a very rough prototype that can be submitted for peer review on
methodology, etc.
Diez B. Roggisch
> I put a little thought into it and I believe the schema method
> probably would work pretty well, however, it isn't a generic solution
> and would be rather complex to deploy on more than a one-off solution.
>
> What I thought about was doing something along the lines of TableForm,
> but call it MultiPageForm. Each Widget in the widgetlist would have
> an additional parameter of the page number. The template and
> rendering would then determine which widgets to display based on the
> active page number. With the use of hidden fields could determine
> what validation would need to be performed on each step, and would
> allow forward/backward navigation of the form.
I would suggest a different approach which is more flexible and doesn't make
rather dumb leaf-widgets need to know anything about them being part of
something larger.
Write a multi-step-form that takes a list of "normal" forms.
On display, there is a parameter that determines which of the child-widgets
is to be rendered. This form gets rendered normal, all preceding ones get
their values rendered into hidden formfields. The question is if this can be
done by "injecting" a child-widget into the respective forms - then you can
use whatever form you want.
If not, the sub-forms need to be able to suppress their form-tag-rendering.
Which is a slight duplication of existing code.
But with this approach, you can use whatever leaf-widgets you like, and don't
need to make them aware of their containing environment.
Diez
cd34
On Nov 5, 5:54 am, "Diez B. Roggisch" <de...@web.de> wrote:
> > active page number. With the use of hidden fields could determine
> > what validation would need to be performed on each step, and would
> > allow forward/backward navigation of the form.
>
> I would suggest a different approach which is more flexible and doesn't make
> rather dumb leaf-widgets need to know anything about them being part of
> something larger.
so that each TableForm would be independent and the widgets would not
need to be aware of the fact they were in a multi-page form, but, in
looking at the code, I wasn't able to see how to populate the hidden
fields of a separate form object for rendering.
I would guess the wrapper class could inject the hidden fields into
the form, but, validation would need to be handled somehow. Perhaps
submit the dictionary to the existing validate decorator for the
previous pages. At this point, I'm still poking through ToscaWidgets
and learning its capabilities.
Figured I would ask before reinventing the wheel.