On Jan 13, 2007, at 1:21 AM, Lee McFadden wrote:
>
> On 1/12/07, Christopher Arndt <[EMAIL PROTECTED]> wrote:
>>
>> You should use 'tg_include_widgets' and then you could use JS/CSS
>> with widgets
>> again too.
>>
>
> That's fine, if you want the JS/CSS and to show up on *every page* of
> your site. If you ended up with a lot of JS heavy widgets your page
> load times will suffer and I don't think it's the best way of doing
> it.
>
>
>> Both both solutions, yours and mine, are only useful for widgets
>> that appear on
>> every page, aren't they? Or do you have special logic in your
>> variable
>> providers to include only specific widgets on a per-request basis?
>>
>
> More or less. Since widgets are designed so one instance of each
> widget is used throughout the site, all adding the instances to the
> variable providers is doing is making that particular namespace
> available in the view, instead of making the widget available to the
> view via the controller's returned data. The downside of this is that
> the widgets don't get "scanned" so their JS/CSS counterparts are
> injected into the template header automatically.
>
> Your method makes all of the widgets available to the view on every
> page view and, IIRC, the JS and CSS will be injected into the template
> header for every widget in `tg.include_widgets`.
>
> Your way gives more bulky page loads but is more automatic, my way I
> have to add the JS/CSS manually to each particular view, but is more
> streamlined as you won't get JS/CSS included that's not being used.
>
> As I say, I believe that a new mechanism for adding widgets is
> required to separate the MVC a little more. Otherwise one would have
> to create two versions of the same method if you wish to use a widget.
> One with the widget in the return value and one without. Not very
> DRY.
What I'm doing in some pylons apps I'm using ToscaWidgets with is
adding them to a list at request-local variable 'c' at attribute 'w'.
Then I scan that list for js/css before every render. To emulate tg-
include_widgets just change 'c' for 'g' which are globals which live
for the lifetime of th application.
I guess some similar solution could be applied to TG (2.0 since 1.0
is in feature freeze). The important thing is to have a request-local
storage area outside the dict that controllers return to store
widgets, however, controllers still have to populate that list so a
little coupling between C and V still occurs.
One idea that has been floating around my head is to encapsulate the
whole page view (everything between the <html> tags + doctype) into a
widget. Widgets as we know the would be children of this "page-
widget" which would be initialized once at app init. That would
remove all widget logic completely from controllers (except choosing
the widget we want for the view like we choose a template with expose
ATM) and has the advantage that the page-widget could always pull js/
css correctly as it knows who it's children are. This page-widget
could be created automatically by "expose" (at declaration time)
taking the template argument plus a new "widgets" dict with the
widgets we need for that view:
@new_expose(template="foo", widgets={....})
def do_something(...):
# do something
return view_agnostic_data
Sounds reasonable?
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?hl=en
-~----------~----~----~----~------~----~------~--~---
