Hi, Alberto Valverde schrieb: > Have you tried displaying the widget? This attribute only gets used > when displaying nested widgets.
yes. > > request.tg_widgets_path is a stack where widgets store themselves (+ > other information) when being displayed (or in any method decorated > by update_path) so they know their position in the widget tree > ( example form -> fieldset -> repeateing-fieldset1 -> text_field). > This is needed to compute their effective name so that when the data > is submitted, FE's NestedVariables can recreate the nested structure. yes I realized that. Actually I am trying to create new widgets, with such nested structures: form - containerwidget - widget, but I am failing in getting the correct nested path :-( > > No wonder you're confused ;) (To be frank, I'm too ;) ) This "path > acrobatics" is something I want to remove in trunk (http:// > tinyurl.com/jbtme). that's good news! The code seems to be very complicated. > I didn't want to mention it just yet as it's in a half baked state > but early this week I started experimenting with a complete widget's > API rewrite and the results ATM look very promising (this comment > belongs to TG trunk really): > It removes the dependency from TG and CP completely, genshi as the > main templating language, much saner compound widget's creation, > doesn't require request-local storage to save state (by, bye path), > it rolls and it dices ;) > > I expect to make something public next week for review, stay tuned at > the trunk ML. > Ah, OK that's good news. Then I'll wait with my widget a little bit. (work with a workaround in the meantime) -- Greg --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
