Re: [Repoze-dev] repoze.plugin documentation
On Tue, Apr 28, 2009 at 3:01 AM, Malthe Borch mbo...@gmail.com wrote:
2009/4/27 Chris McDonough chr...@plope.com:
Answering myself with the kind of navel-gazing which is sure to drive
Tres
nuts ;-):
Not answering anything, but this thread is as good a place as any:
I think the issue of overriding default components is unnatural.
Rather, I'd like to think of components in terms of availability,
rather than pluggability. Concretely, the following is *pluggability*:
by_interface = {}
Plug me once, you'll plug something out if you try it again.
That's not what the ZCA is about; I think it's rather about
availability, e.g. if I give you these N things, give me something
that provides some formal functionality (described by an interface).
The problem with this line of thought is that it breaks down when you
abuse it to multiplex user interface elements; because here it's not
about availability, it's about multiplexing.
I think we should reconsider the way we decide on views and related
components. Perhaps using a routes-like approach, e.g.
browser:page
...
for=.interfaces.IHelpCenter .interfaces.IDocument
/
(to target documents inside the help center section). Or whatever
language/abstraction that can fit the bill. Note that to match this
for clause, something more than a simple component lookup is
required.
I'm not sure that I see the need for that personally, but maybe it just
hasn't sunk in yet why I'd want to do that.
I did want to go ahead and bring up a completely different use case that is
very common in the wild but doesn't seem to be addressed in ZCA or this
generic formulation. Let's call it the Photoshop model, since hopefully
everyone knows what Photoshop plugins are. You have N number of plugins
that define a particular interface that are all registered but with no
preferential treatment in terms of look up--just a list of things you could
possibly use, with choice driven by the user.
registry.look(img_processor)
[ FuzzyCloudsPlugin ojbect at 0x, SatanicRequestPlugin at
0x, GreeneryPlugin at 0x, etc...]
or maybe a dict, more like:
registry.look(img_processor)
{ 'Fuzzy Clouds': FuzzyCloudsPlugin ojbect at 0x,
'Satanic Request': SatanicRequestPlugin at 0x,
'Greenery Plugin': GreeneryPlugin at 0x,
etc...
}
Now, I have no idea whether or not we actually care about this use case. An
application that uses plugins like this could easily define it's registry
and registration process. But, it had occurred to me, that if you're
throwing around the word plugin to people not already familiar with ZCA, a
lot of people are going to be thinking this model.
Chris
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
2009/4/28 Chris Rossi ch...@archimedeanco.com: ``zope.component.getAllUtilitiesFor`` does that. Might be called ``getAllUtilitiesRegisteredFor``, although there's another variant, too, ``getUtilitiesFor``. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Genshi match templates without ``lxml``
Adressing the Repoze-list here, since Chameleon is currently kept in this repository. For those not in the know (certainly before I read the documentation[1], I was one of them), Genshi has a feature called match templates which lets you first render a template, then apply a second template to elements matched by an XPath-expression. If this sounds a bit strange, it's because it is––but it's useful because it can be used to sculpt HTML in a way similar to Deliverance and/or XSLT. At any rate, it's a Genshi feature and we do support it in ``chameleon.genshi``. Problem is, ``lxml`` is required for this to function––what's more, this solution is suboptimal in terms of performance (which is the raison d'etre for Chameleon in the first place). There are two scenarios: 1) Match templates are defined and used on elements appearing in the same template; 2) Match templates are brought in through an XInclude, dynamically, at render-time. Assuming we know how to match elements using XPath, the first scenario is reasonably easy; the difficult being only that the XPath ``select`` method (corresponding to the matched elements) must be made available. The second scenario is more difficult, because these includes aren't predictable at compile-time; as such, we have to match elements as we render and apply the templates. As mentioned, this is currently solved by post-processing the output using ``lxml`` and applying match templates using callback-methods. It's not horrific, but it's also convoluted and slow–––and slightly buggy. However, I think there's a way out of the deadlock. If we compile the template specifically for each XPath-expression (on-demand, of course), we can match the elements at compile-time and have a situation similar to (1). This leaves us with the task of porting/writing an XPath selection routine; it needn't be complete I think (Genshi's surely isn't). \malthe [1] http://genshi.edgewall.org/wiki/Documentation/xml-templates.html#id5 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Genshi match templates without ``lxml``
Well, this is pretty doggone interesting. I do worry that the last sentence is pretty optimistic. I wonder, in light of our #repoze discussions about theming, what you think this would mean if the stuff below landed? --Paul On Apr 28, 2009, at 11:41 AM, Malthe Borch wrote: Adressing the Repoze-list here, since Chameleon is currently kept in this repository. For those not in the know (certainly before I read the documentation[1], I was one of them), Genshi has a feature called match templates which lets you first render a template, then apply a second template to elements matched by an XPath-expression. If this sounds a bit strange, it's because it is––but it's useful because it can be used to sculpt HTML in a way similar to Deliverance and/or XSLT. At any rate, it's a Genshi feature and we do support it in ``chameleon.genshi``. Problem is, ``lxml`` is required for this to function––what's more, this solution is suboptimal in terms of performance (which is the raison d'etre for Chameleon in the first place). There are two scenarios: 1) Match templates are defined and used on elements appearing in the same template; 2) Match templates are brought in through an XInclude, dynamically, at render-time. Assuming we know how to match elements using XPath, the first scenario is reasonably easy; the difficult being only that the XPath ``select`` method (corresponding to the matched elements) must be made available. The second scenario is more difficult, because these includes aren't predictable at compile-time; as such, we have to match elements as we render and apply the templates. As mentioned, this is currently solved by post-processing the output using ``lxml`` and applying match templates using callback-methods. It's not horrific, but it's also convoluted and slow–––and slightly buggy. However, I think there's a way out of the deadlock. If we compile the template specifically for each XPath-expression (on-demand, of course), we can match the elements at compile-time and have a situation similar to (1). This leaves us with the task of porting/writing an XPath selection routine; it needn't be complete I think (Genshi's surely isn't). \malthe [1] http://genshi.edgewall.org/wiki/Documentation/xml-templates.html#id5 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
