On 1/13/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
>
> 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?
Couldn't that be added to the current expose decorator too? no need
for switching over to page widgets just for that.
> Alberto
>
> >
>
--
cheers
elvelind grandin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
