Diez,
Thanks so much for the answer, I don't feel so crazy now :) "Its not
possible" and the original TG1 code is abusing the underlying classes/
library is what I thought. So what I am trying to do is this in a
couple of different areas:
1. Present a user profile form that has a variable number of fields.
Data is "progressively" collected about a user elsewhere so sometimes
there is a reason not to show a user a form field for data not yet
collected.
2. Another use of this is that I have what is the equivalent to a
custom search form. However, the controls/fields on this form will
vary depending on where they are in the site. So, as an example where
this specifically happens is in generating a series of checkbox lists
grouped by "categories" where each category is its own checkboxlist
widget with its own options.
So, I figure the solution here would be just to create a new form
widget per request that initializes the fields it needs. Is there
another route? It just seems like creating variable field forms
shouldn't be so difficult; unless I'm not understanding something here
and just need to arrive at the, doh! moment! with TW.
Here's a simplified pseudo code of what I am thinking...
-- In root.py
def subject(self, subject_id, *args, **kwargs):
fields = someMethodToDetermineFormFields(subject_id)
# ^^^ returns a list of field widgets based upon data related to the
subject_id
child_args = someMethodToDetermineChildArgs(subject_id)
# ^^^ Returns a nested dict to be passed to the form for childargs.
myform = SubjectForm("myform", fields=fields,
child_args=child_args)
# ^^^ Now based upon the subject data, different child fields will
need to be rendered.
return dict(myform...and other items to the template)
See any gotchas with this approach?
On Aug 14, 1:04 am, "Diez B. Roggisch" <[email protected]> wrote:
> John Lorance schrieb:
>
>
>
>
>
> > I'm converting a TG1 app with TG1 style widgets and am finding that a
> > code pattern implemented to add widgets on the fly in TG1 doesn't work
> > in TG2/TW. Basically, in an existing form's update_params method,
> > new fields were being added to a fieldset based upon parameters of the
> > request/data in model. This strategy doesn't seem to work in TW. So,
> > my questions is what is the best way to create a form that adds
> > widgets dynamically?
>
> > So far it seems that I need to instantiate a new form widget object
> > for each request and pass it a fields parameter that is the set of
> > fields needed for the given request. For example,
>
> > myfields = [TextField("a"), TextField("b")]... etc
> > myform = MyForm("formname", fields=myfields)
> > myform.display(**params) # pass non-field items in display.
>
> > Is this the best approach, or is there a better way that can more
> > mimic what was possible with TG1 widgets?
>
> If this worked with TG1 it was pure luck that you didn't run into
> concurrency issues. TW tries to lock-down widgets after instantiation
> time. This obviously has it's limits, but in this case it caught the
> "abuse".
>
> By modifying widgets like that at runtime, you modified a single
> instance which was used to render concurrent requests. If the load is
> not to heavy, that works. If it ramps up, errors will creep in when two
> requests modify the widget before it is rendered.
>
> So, the answer is: it isn't possible, and it wasn't really a good idea
> in TG1 as well :)
>
> Now the question is: what kind of dynamic alterations did you actually
> need? Can you please give an example of that, then we can think about a
> conformant 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
-~----------~----~----~----~------~----~------~--~---
