On Sep 22, 2006, at 5:28 PM, Ben Bangert wrote:
> > Alberto Valverde wrote: >> I'd like to hack a bit when I get the time on packaging all the >> widget code into a separate egg which could be reused on any >> framework supporting template plugins + genshi (or any template >> plugin of your choice thanks to #1086 + formencode. >> >> I'll try my best on keeping the API backwards compatibility intact >> but I'm not sure yet of how easy a task it would be. >> >> What worries me most is that, in order to avoid the dependency on >> cherrypy, I plan to remove the "path" acrobatics which depend on >> cherrypy.request and I need to think of a way to let child widgets >> get their display parameters and validation errors: >> a) without changing the API (this means not passing "errors" as a >> parameter to the form's display when rendering it on a template. >> b) letting widgets be child's of many widgets at the same time (to >> allow WidgetsLists to be reused). This means no modification to child >> widgets when attaching them to a container, for example, by adding a >> 'parent' attribute. >> c) keeping them threadsafe and without using threadlocal storage >> (like cherrypy.request) >> >> This "acrobatics removal" should greatly simplify the code too I >> believe... Let's see how it goes when I give it a shot. >> >> Any suggestions, requests, objections or anyone wants to lend a hand? > > I'm interested in helping out on this. I was just talking to some > folks > the other night about adapting TG widgets to work like that. If I > could > get some pointers on what sections of code I should be taking a look > at, it'd be easier for me to get up to speed on possible ways to > resolve the CP dependencies. > Nice :) Some bacground info first. Widgets depend on cherrypy exclusively for the cherrypy.request threadlocal storage. This is because they need to store some state there (path, number of repetitions, etc...) when being displayed so nested input widgets can encode their names in a way FE's NestedVaribles validator can unflatten the variables being submitted. http://formencode.org/module- formencode.variabledecode.html. Oh, and to fetch validation_errors and input_values so forms can display them when validation fails. You should study widgets/forms.py until line 519, specially all the ".*path.*" functions and the update_path decorator. I was thinking in the line of passing this state explicitly through the display() parameters to child widgets, but we have an API problem when displaying the form on a non-widget template because, ATM, validation errors and input values are fetched from cherrypy.request so they don't have to be passed explicitly to the form's display. Some discussion on this took place a while ago at ticket #613 RFC, How bad would an API break be which involved passing tg.errors and tg.input to the form's display in a template? I't will surely simplify *much* all the forms' code, remove a little bit o' magic and remove the cherrypy dependence. Well, this is just my opinion... I'm sure there are dozens other ways to accomplish the same goal probably through a better "path" ;) Thanks, Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk -~----------~----~----~----~------~----~------~--~---
