Hi guys,
what about totally changing the way variable providers works?
My idea is to check for a special method inside the actual controller
that returns a dict of variables that will be injected inside the dict
returned by every method of that controller, this allows for great
flexibility combined with OOP.
Let me make an example:
class BlogController(Controller):
def __variables__(self):
return dict(cool_widget=cool_widget)
def list(self):
return dict(notes=notes)
the save method will always return cool_widget and notes.
If you need something on every page you can subclass Controller and use
it in every controller instead of the original one, you can also mix
things as you need.
Ciao
Michele
Alberto Valverde wrote:
> On Jul 31, 2006, at 10:32 PM, Kevin Dangoor wrote:
>
> >
> > On Jul 16, 2006, at 8:34 PM, Christopher Arndt wrote:
> >
> >> how can I inject a widget into the template variables without
> >> explicitly
> >> including it in the returned dict of a controller method?
> >>
> >> I know about view.variable_providers, but unfortunately
> >> controllers._process_output() does not retrieve CSS or JavaScript
> >> from
> >> widgets in the 'tg' namespace.
> >>
> >> I guess, my only option would be an ugly hack by saving
> >> view.stdvars()
> >> somewhere and then overriding/wrapping it with my own version that
> >> adds
> >> my widget to the toplevel namespace of the template variables. But
> >> this
> >> would be, well, ugly.
> >>
> >> Any suggestions? If you are wondering about the need for this: I
> >> want to
> >> replace $tg_flash with a nice widget (I'll be releasing a demo
> >> soon)
> >> that needs some CSS and JavaScript, and thatswhy I can't just add
> >> it to
> >> the controller output.
> >
> > I didn't see a reply to this, but it sounds useful. Some people have
> > wanted variable_providers to be able to put things outside of the tg
> > namespace. That might be one way.
> >
> > How would you *like* it to work?
>
> Hi,
>
> I've been tinkering sometime ago trying to implement this feature
> (retrieving js, and css from widgets present in stdvars) and found
> out that in order to implement it some change might be needed in the
> way stdvars are sent to the engine:
>
> So, IIRC, not on crack or way too sleepy, I've seen that the engine
> is initialized with a callable, ("stdvars" in our case, http://
> tinyurl.com/je2td), which is called inside the engine to populate a
> dict with extra variables.
>
> The problem with this approach is is that this dict is built outside
> TG in the template engine, hence we have no chance to inspect it to
> see if any widgets are present and "pull" their resources from them.
> At least I couldn't find a way to do it. Mainly because a check for
> "isinstance(obj, Widget)" inside the engine would couple it
> unnecessarily with TG.
>
> This could be easily solved if stdvars was called inside TG (in
> view.render(), for example), the dict produced was inspected there
> and it's resources pulled out and prepared to be included in the
> template.
>
> I got a semi-working patch (just some polishes needed to pass all
> tests) using the approach I mentioned which I could dig up from the
> dustbin if I'm going in the right direction.
>
> BTW, this is related to ticket #692, so we might as well move the
> technical discussion, patches, etc, there ;)
>
> Alberto
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
