I just started with TG and wonder whether there is something special you wanted to tell about self-reference, as promised at the end of part 3, that I could not figure out (most probably).

I’m not sure my message got through as I intended it…

It’s not a solution to include *Links and *Sources in templates, but a solution to make sure that widgets that we really need in every template to be treated in the same way as if they were returned in the dict controllers return, that is, their resources automatically included so the widget behaves as intended.

For example, I have an app. where master.html (using genshi) includes a search form widget that shows up in every page. That search form needs to include an async.js link (it shows results asyncronously in the main div) and autocomplete.js (it autocomplete’s results a là AutoCompleteField).

If I just dump this widget in variableproviders it’s required resources won’t be included because the code in turbogears.controlles.process_output that picks up widget’s resources from the dict that the controller returns doesn’t see those variables (as they’re sent directly to the template engine plugin).

I agree that it should be used with care as we don’t want unneeded links included in every page, but sometimes this is what we need.

It’s a solution for the problem mentioned in http://trac.turbogears.org/turbogears/ticket/847
(which I’m about to close ;)

Regards,
Alberto

I didn’t think about using the tg.include_widgets config option, but I don’t particularly like it as a solution to getting JSLink/JSSource or CSSLink/CSSSource widgets to show up in the templates - if you have a lot of widgets that could end up being a lot of code that is inserted on every page view.

It might be an idea to have a conversation about this on the mailing list with regards to ToscaWidgets to see if there’s any way around this potential issue.

I just wanted to comment Lee’s comment a couple of lines back… The best way to have widgets available at every template is to list them in the tg.include_widgets config variable.

For two reasons:

1) Any JS and CSS needed by widgets listed there will get included in the template too (doesn\’t happen with variable_providers, unfortunately)

2) You can control the order in which those resources are included (only in the 1.0 branch in Subversion, ATM, 1.0b2 will include it). This doesn\’t happen when you dump widgets in the dict returned by the controller because iterating it doesn\’t guarantee any ordering and could be the cause (has bitten in the past) of some mysterious bugs. For example, if mochikit gets included after a JSSource that needs it.

Widgets listed at tg.include_all will appear in the template as tg_${widget_name}. For example, myapp.widgets.show_user will be tg_show_user in the template.

Your tutorial is way coool! Learned a lot. Thanks a lot! :)

Part 4 needs one change, where it says to Open the new, blank file, postdisplaytemplate.kid, the name should be postdisplaywidget.kid.

Also, on your web site the “simpleblog” category is missing part 2 (tag missing I guess).

For anyone who doesn’t want to wait, I generally create a simple object, adding each widget as an attribute. I then add this object to TurboGears’ variable providers:

from turbogears import view

class ProviderObj(object):
    def __init__(self, *args, **kw):
        for k,v in kw.iteritems():
            setattr(self, k, v)

append_providers(vars):
    vars["mywidgets"] = ProviderObj(widget_name=widget_instance,
                                    another_widget=another_widget_instance)
view.variable_providers.append(append_providers)

This means that I can then access every widget from the template via ${tg.mywidgets.widget_name} or ${tg.mywidgets.another_widget}.

This preserves the designed use of widgets (i.e. one widget shared between all of the apps threads) and the MVC paradigm.

Otherwise a great tutorial.

jtate