On Sep 22, 2006, at 11:35 PM, Kevin Dangoor wrote:
>
> We've tended to use the request has a threadlocal, request-scoped
> storage. You'll find evidence of that in turbogears.widgets.forms.
> That should actually be a pretty easy one to fix if the WSGI
> environment becomes available.
>

I'd rather "fix" this without using request-scoped storage altogether  
as I believe it would simplify the code in a great deal (let's see if  
it's true once I get my hands dirty on it) and achieve better  
performance (this storage is accessed many times when rendering a form).

This storage is used to keep a "path" stack where widgets push  
themselves when being displayed to keep track of their position in  
the tree. I think this could be better achieved by passing this state  
as a parameter to display(). Or maybe just by setting a reference to  
the parent in a "parent" attribute to widgets once they get attached  
to a CompoundWidget. However, this last approach would require us to  
clone the widgets when they get attached in order to allow  
WidgetLists to be reused.

Well, this are just some random thoughts as I still haven't looked  
into it in much depth (read, haven't touched a line of code yet ;) )


On Sep 22, 2006, at 11:41 PM, Kevin Dangoor wrote:
>
> On Sep 22, 2006, at 12:51 PM, Alberto Valverde wrote:
>
>> 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.
>
> (...)
>
> I'm still not favor of this. While I agree that it's explicit, I
> think it's also annoying. If we can make the WSGI environ available
> to the things that need it, this shouldn't be a problem.

Hmmm, I got myself mixed up when I claimed that "I't will surely  
simplify *much* all the forms' code". This would be accomplished by  
the "path" stuff I mentioned in the previous paragraph, not this.

Validation errors and input values could surely be fetched from  
environ instead of CP.request to make the API nicer (and remove logic  
form the template as what I suggested would require to discern at a  
template/controller level if the values received are previously  
submitted values). Bottom line: forget that last RFC ;)

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to