> Do you mind sharing how you implemented those dynamic forms? Namely,
> the displaying of different input fields according to the drop down
> selection.

We use templated forms. When this was discussed in #weblocks there was some
opposition as this was considered "not the right way" to go, although my
personal opinion is that since templating is used in almost all other web
frameworks, why not make it an option with weblocks?

Essentially all my forms consist of html fragments where weblocks' defview
fields are baked in using standard html-template syntax:

Eg (skipping all the table, div definitions):

  <div id="dann">
<label class="desc_nobold">Telefono</label>
<!-- TMPL_VAR complainant-phone --> </td>

Now the defview needs to only contain the field complainant-phone, and using
the id "dann" one can hide and show different parts of the form (IOW, do
grouping of fields).

In addition, using this mechanism, views can contain other widgets (but it
is very kludgey atm).

> For your reference, I asked a similar question before and here is the
> thread:
http://groups.google.com/group/weblocks/browse_thread/thread/9322be69...

In that thread, I said:

 I can't suggest this approach (though it works) because it all depends on
> using

templated form views(which is why I can easily identify the divs that need

to be hidden or shown, something that's hard to do with regular form-views;

divs also serve as a unit of grouping, grouping is also handled well by the

wizard-form)


I also posted code to show what the defview looked like.

How much of a hard requirement is hiding/showing of fields for your app?
Does wizard form not suffice for the moment? Some others have opted to do
the form-handling outside of weblocks, iirc. If that suits you, perhaps you
can use something like inputex/yui?

In our case, we use so many forms that we pretty much chose weblocks for its
declarative form handling. Unfortunately the defview syntax didn't cover
several common needs, eg grouping of fields, dynamism of various sorts etc.
-- our solution is kludgey and unfit for inclusion in weblocks though.

-- 
You received this message because you are subscribed to the Google Groups 
"weblocks" 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/weblocks?hl=en.

Reply via email to