I don't understand what you just said :-) My fault -- I haven't been plugged into the other discussion.
Is there a branch somewhere that has a simple demo to help with grokability? -- Garrett On Friday, September 16, 2005 12:28 PM, Gary Poster wrote: > On Sep 16, 2005, at 12:49 PM, Garrett Smith wrote: > >> Sorry for the long delay in replying. >> >> We've been using widget-specific JS and CSS for some time now and I >> like our approach. It's quite different from the proposal. >> >> We're using the same pattern used by forms/widgets -- i.e. the PT >> is responsible for explicitly including HTML fragments provided by >> the view. As a point of reference, here's a simple example of >> including widgets: >> >> <tal:block repeat="widget view/widgets"> >> <label tal:content="widget/label">Name</label> >> <input type="text" tal:replace="widget" /> >> </tal:block> >> >> The analog for including header support (i.e. JS and CSS) is: >> >> <head> >> <tal:block repeat="content view/headContent"> >> <tal:block content="content" /> >> </tal:block> >> </head> >> >> This places the burden of managing unique lists of 'head content' >> with the view. I see this as an extension of the widget-management >> framework. >> >> I would not personally opt for the proposal because it feels a bit >> magical -- I think it's too indirect. >> >> So, here's my argument in brief: Since widgets are driving the >> requirements of a consolidated "resource" list in the HTML head, >> the solution should extend the existing widget pattern. Yes, this >> imposes more overhead on the PT and the view, but the upside (IMO) >> is that the scheme is more transparent. > > If we had a clear division between update and render stages, and all > template elements had an update call before they were rendered (and > so were able to register a need) then the approach you suggest would > be generally sufficient for the kind of story we are interested in > telling. Pipelining, possibly combined with a modified templating > story, can address this in a different way--one of the simplest > configurations would support something like separate update and > render stages. Even there, though, the resourcelibrary API for > clients could remain the same, whether the JS/CSS were inserted by a > main template that rendered the gathered JS/CSS calls, in a modified > version of your approach; or by the XML-munging (or "transformation" > to put it in a more politically appealing light) that is the current > implementation. > > I'd say that this proposal has two thrusts. > > First, it proposes that we need a solution to the problem of stand- > alone display components that need support from the main page. > That's something that we (ZC) want, and for which other replies to > the thread have also expressed desire. It enables a drop-in rich- > widget story, which is arguably becoming more important as user > expectations for richer internet experiences rise, and developer > expectations for simpler integration of rich client technology rise. > > Second, it proposes that the given API can support a number of > rendering implementations, from transforming HTML (as in the current > implementation) to being a part of a wrapper main template during a > rendering stage of a pipeline. > > The proposal should be evaluated from that perspective, and from the > perspective of Jim's recent pipeline discussion. Can you see the > need? Can you see how the API can support several rendering > implementations? Developers who say yes to both can develop and use > drop-in rich sub-page components, such as widgets. > > Developers who say yes to the first but no to the second are > urged to > suggest improvements. > > And thanks to the wonder of the more plug-and-play architecture of > Zope 3, developers who say no to the first question don't have to > play here, while still joining up elsewhere. :-) > > Gary _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
