Re: [Repoze-dev] repoze.plugin documentation
2009/4/29 Chris McDonough chr...@plope.com: When you do need it, the multiplexing is awful handy (e.g. when trying to look up a view based on a context type and a request type). Except there's always this situation: View 1) for=IDocument IRequest View 2) for=Interface IPostRequest Let's say that you wanted always to do something special for POST requests. This won't work; you have to change (1) to for=IDocument IGetRequest I find that the ordering of multi-adaptation hinders me in using them in a clean way; perhaps the solution is to have some kind of priority token, e.g. for=Interface +IPostRequest You can argue that anything more than we have now is too complex; still, for multiplexing, the default adaptation ordering isn't always desirable. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
One of the epiphanies Tres came up with during a bout of drinking is that the #1 navel-gaze below (the unittest indirection one) doesn't need a ZCML registration (or any real component registrations at all except in the unit test). Instead, to do unit testing indirection, say for a test like so: def test_it(self): from something import view context = DummyContext() request = DummyRequest() result = view(context, request) def factory(context, request): return DummyImplementation() provideAdapter(factory, (None, None), ISomeUnitTestIndirection) self.assertEqual(result.status, '200 OK') Where the 'from something import view' might resolve to: def view(context, request): impl = queryMultiAdapter((context, request), ISomeUnitTestIndirection) if impl is None: impl = TheRealImplementation(context, request) return Response(impl.render()) This is as opposed to doing: def view(context, request): impl = getMultiAdapter((context, request), ISomeUnitTestIndirection) In the second view variant, the unit test indirection would need to be registered in ZCML or elsewhere. In the first one, it needn't be, except within the unit test itself. The main benefit of this is that registrations made only to service unit tests don't need to pollute ZCML. - C On 4/27/09 2:56 PM, Chris McDonough wrote: On 4/27/09 1:18 PM, Chris McDonough wrote: I find the introduction lacking; why do I care about indirection, what's the benefit. Good point. Um. Why *do* we care about indirection? In particular, why do we care about this sort of generic-function-ish dispatch pattern we call adaptation? Why do we care about it for *every* application? I'm too brainwashed to answer that question without thinking about views. If we want something to be bit off by the larger Python community, we need an answer for this. Answering myself with the kind of navel-gazing which is sure to drive Tres nuts ;-): - We use the heck out of indirections during unit testing. In most of the apps I write personally, the ZCA indirections are the only thing that make it *possible* to write unit tests rather than needing to write functional tests. But typically during testing the idea that some *adapter* is registered against more than one requires interface is just something that we deal with rather something that is actively desirable (because we always only have one implementation during unit testing); the actual multidispatch is to support the below case. - We use adaptation and utility indirections in applications to allow people to override implementations without needing to change the code. Most non-Zope people associate this desire to provide pluggability, correctly or incorrectly, with CMS systems. But there's something to this conclusion because indeed the ZCA indirections were originally meant to replace use of something like acquisition to find values in content space. I suspect we are quite brainwashed here, or at least incapable of discounting this use case, because we tend to treat every application as something that might turn into a framework. - We use utility indirections (or at least I do) to retrieve application-specific configuration values (e.g. BFG's ISettings utility, which offers no behavior except as a bag-of-names). I have some ideas about how you might layer several systems together to allow people to only bite off one bit of software for each of these cases. #2 is the most problematic and would be at a higher layer. - C ___ 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
Re: [Repoze-dev] repoze.plugin documentation
2009/4/29 Chris McDonough chr...@plope.com:
That seems completely broken to me. It also doesn't match my (limited)
experience but I've never fought with it hard enough to know.
That should have read: adaptation is like an alphabet:
ABZ
ABC
ZBC
The real problem with doing the more clever thing is that it's just too hard
for any actual human to know what's going to happen. And the only real way
to fix that is to simplify the implementation, IMO. Indicators like + in
front of interface names makes me think of:
#div {
color: blue !important
}
.. and we all know how fun that is.
Hey, I... fine.
\malthe
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On Apr 27, 2009, at 1:31 PM, Reed O'Brien wrote: On Apr 27, 2009, at 1:18 PM, Chris McDonough wrote: I'm actually having a bit of trouble naming those things. At first they were called plugin types, then provides types, then finally component types. None of those names really work for me. Why not just markers? or in the spirit of plugs, prongs For whatever reason this has been stuck in my head... In Erlang they refer to protocol pattern abstractions as 'behaviours'. Perhaps that is good candidate here, as well. ~ro smime.p7s Description: S/MIME cryptographic signature ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: On 4/28/09 3:01 AM, Malthe Borch wrote: snip 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. A fish doesnt know from wet, but I think if you were to want to go after some dispatch like this, you might as well just use some URL dispatch thing like Routes itself, because it ties the traversal path (at least in some abstract sense) to a view. And once you do that, you might as well just use a regex against the path itself to make it more flexible. Or use something like repoze.uripace which does the pattern match against the path and adds keys to the environment. Hmm, we might extend the request factory to use those keys to establish the marker interface / layer of the request. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ+Fvc+gerLs4ltQ4RAuPXAKCZwDM1n16XSsI2JgABlZltQkV6cACdERBX E67sTWAmuu8NGKrkPWeHBLo= =BVkg -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On Wed, Apr 29, 2009 at 1:35 AM, Chris McDonough chr...@plope.com wrote:
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.
A fish doesnt know from wet, but I think if you were to want to go after
some
dispatch like this, you might as well just use some URL dispatch thing like
Routes itself, because it ties the traversal path (at least in some
abstract
sense) to a view. And once you do that, you might as well just use a regex
against the path itself to make it more flexible.
OK, so this finally made me think of a place where Routes pluggability seems
sensible. (I think a predecessor to repoze.plugin was Chris thinking about
how Routes might be pluggable ala ZCA -- but we never came up with a use
case for that pluggability.)
Anyway, I could imagine the desire to, say, mark a set of pages/routes with
a variable that isn't exactly used for routing. For instance:
map.connect('/help', controller='help', template_path=site_templates)
map.connect('/docs', controller='docs', template_path=site_templates)
Then somewhere else you might have:
def render(template_name, **kw):
req = get_request()
path = req.urlvars.get('template_path', standard_template_path)
tmpl = load_template(os.path.join(path, template_name+'.html'))
...
So it makes sense to make that pluggable. Except... you don't actually want
to plug the Routes, because the routes for the application might not have
any relation to the template paths you have. Instead you might just want to
annotate the request, which I guess is what Tres is suggesting with
repoze.uripace.
OK, but here's a more serious pluggability thought. Let's say there aren't
static routes you want to capture. Let's say you have a structure like
/client/{client_slug}/ticket/1, and you want to allow clients to overload
templates. You might want to instead do:
def client_render(template_name, **kw):
req = get_request()
path = os.path.join(client_templates, req.urlvars.get('client_slug',
'default'), template_name+'.html')
if not os.path.exists(path):
path = os.path.join(standard_template_path, template_name+'.html')
tmpl = load_template(...)...
And then you want to register and configure this template loader, and
presumably the framework or application uses:
def render(template_name, **kw):
renderer = registry.lookup('template_renderer')
return renderer(template_name, **kw)
This stubby indirection is kind of lame, but you don't very well want every
code path to have to grab a template_renderer, it's better to import this
one render function.
Some questions that come to mind:
When I was discussing cases like this with Rob Miller, we also found most
plausible pluggability points required specific configuration. For this
example there's the client_templates value. You could possibly have a more
generic pluggable component that took configuration
/site/client_templates/${client_slug}/${template_name}.html and did
substitution, making it more loosely bound to the particular urlvars you
define. But regardless, configuration that is specific to both the
deployment and the specific registered implementation seems essential, and I
believe should be a first-class patter.
Also, at least half the time or more I think a function is going to be
registered. There seems to be a class bias in several places, though maybe
I'm misreading that.
An ambiguity: for this case, do you plug in the render function, a
load_template function, a function that calculates template_name...? Each
seems plausible, but the ambiguity is a bit purturbing.
--
Ian Bicking | http://blog.ianbicking.org
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On 4/29/09 4:32 PM, Ian Bicking wrote:
Some questions that come to mind:
When I was discussing cases like this with Rob Miller, we also found most
plausible pluggability points required specific configuration. For this
example there's the client_templates value. You could possibly have a more
generic pluggable component that took configuration
/site/client_templates/${client_slug}/${template_name}.html and did
substitution, making it more loosely bound to the particular urlvars you
define. But regardless, configuration that is specific to both the
deployment and the specific registered implementation seems essential, and I
believe should be a first-class patter.
Also, at least half the time or more I think a function is going to be
registered. There seems to be a class bias in several places, though maybe
I'm misreading that.
An ambiguity: for this case, do you plug in the render function, a
load_template function, a function that calculates template_name...? Each
seems plausible, but the ambiguity is a bit purturbing.
Deciding on any applictation-specific pluggability strategy is pretty hard.
I
don't have any good answers to your thoughts above because you're plugging
things into other things that have no analogue in my development world
(template
loaders, for example). And in reality, I probably shouldn't need to care about
the minutiae of those unless I'm your client and you've sliced and diced the
application just so so I can't screw things up and you've documented all
those
plugpoints.
But FWIW trying to anticipate pluggability by building very granular plugpoints
into app code itself can often be avoided entirely if you provide big hammer
mechanisms that allow clients to override behavior. Instead of trying to
anticipate the client's every override requirement, you just let them register
new routes (or whatever they use for URL dispatch) that point at entirely
different controllers from outside an existing application, overriding routes
that are already present in the application. Routes (the proper Routes), as
used in Pylons *already* makes you specify the controller you want to use as
one
of its vars (at least in the most common case); you'd just take advantage of
that by allowing it to be overridden.
This is a heavy-hammer, least-effort, dumb-as-a-rock way of providing
pluggability to an application. The use case is: I don't really like the
controller that route resolves to; I'll just replace it wholesale, logic,
template loading, templates, and all. It's not very granular, but it's quite
easy to explain. You don't need to torture yourself over where the plug points
are: the application already exposes natural ones via controllers and routes
(or whatever analogues for those things your own app has).
- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
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
Re: [Repoze-dev] repoze.plugin documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: On 4/27/09 1:28 PM, Martin Aspeli wrote: Chris McDonough wrote: But anyway, yeah. For someone who has never used zope.component, though, it's really not that important (more strictly compares to zope.component). Reading that page as someone who does use zope.component, I was also not entirely convinced of the rationale for this package. I'm not saying there isn't one (though it smells a bit unfortunate that we're inventing a plugin system that's almost the same as zope.component, yet incompatible), but the aforementioned documentation didn't explain it sufficiently IMHO. There's no *good* reason. The only reasons are bad. Agreed. The primary driver is that we're trying to work with the Pylons community to share implementation bits. I suggested that they might use something like zope.configuration to do system configuration. But it turns out that some in that community are completely befuddled by zope.component and those in that community who are not befuddled by it are actively hostile to it. They may still be befuddled by and hostile to something that is simpler, but at least we'll have something to argue about on technical grounds rather than emotion. I can't see much reason for us to try to share code with people who won't even attempt a rational evaluation of the candidate. -1 to bikeshedding this thing further; +1 to an 'svn rm'. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9fWD+gerLs4ltQ4RAhfEAJ91VMGLi5IaiKqw3+qQzWLEWJ6h/ACg2vMa G4SaaBCNiVrEutkvt2mSVI0= =0dXZ -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On 4/27/09 2:12 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McDonough wrote: On 4/27/09 1:28 PM, Martin Aspeli wrote: Chris McDonough wrote: But anyway, yeah. For someone who has never used zope.component, though, it's really not that important (more strictly compares to zope.component). Reading that page as someone who does use zope.component, I was also not entirely convinced of the rationale for this package. I'm not saying there isn't one (though it smells a bit unfortunate that we're inventing a plugin system that's almost the same as zope.component, yet incompatible), but the aforementioned documentation didn't explain it sufficiently IMHO. There's no *good* reason. The only reasons are bad. Agreed. The primary driver is that we're trying to work with the Pylons community to share implementation bits. I suggested that they might use something like zope.configuration to do system configuration. But it turns out that some in that community are completely befuddled by zope.component and those in that community who are not befuddled by it are actively hostile to it. They may still be befuddled by and hostile to something that is simpler, but at least we'll have something to argue about on technical grounds rather than emotion. I can't see much reason for us to try to share code with people who won't even attempt a rational evaluation of the candidate. Personally, I think there is benefit to both reaching out to people who aren't quite on board as well as participating in some introspection about why we do what we do. I don't attempt a rational evaluation of, say, Mathematica, because I just can't see how it would help me in my every day life. OTOH, if I had a library that just did simple graphing, I'd have some context as to how it might help me (even if I ended up disusing it anyway). -1 to bikeshedding this thing further; +1 to an 'svn rm'. Bikeshedding? I'm beggining to hate that word. Like Pythonic. I really don't care about the bits; it's more a decomposition exercise. There's always your mailer's ignore thread. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Malthe Borch wrote: 2009/4/27 Tres Seaver tsea...@palladion.com: I can't see much reason for us to try to share code with people who won't even attempt a rational evaluation of the candidate. -1 to bikeshedding this thing further; +1 to an 'svn rm'. I think the primary reason why people shy away from ``zope.component`` is that it's abused too often; it's hard to see that it's really quite simple when some users are multi-adapting four ways to look up a viewlet which happens to rely on twenty other lookups to render itself. I think you are being generous: I have very little doubt that the objections come first from the presence of 'zope' in the package name, and second from the very idea of using a tool which codifies and categorizes abstractions, never mind the benefits. Perhaps if campaigned a bit on the grounds of the relative ease-of-use of the ZCA, we wouldn't have to dumb it down to the level of ``repoze.plugin`` (no offense) in order to get adoption outside of Zope. These are folks who, on the whole, prefer *code generation*, and place and extremely low value on abstraction and pluggable reuse. I don't think repackaging is going to help the gag reflex. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9fiA+gerLs4ltQ4RArkdAJ93UdkIupl5Xa52CHb4A+SmxBRAgQCfeoFW 9SG7sADfzbZehsa5KpQkcOk= =xHg2 -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
On 4/27/09 1:18 PM, Chris McDonough wrote: I find the introduction lacking; why do I care about indirection, what's the benefit. Good point. Um. Why *do* we care about indirection? In particular, why do we care about this sort of generic-function-ish dispatch pattern we call adaptation? Why do we care about it for *every* application? I'm too brainwashed to answer that question without thinking about views. If we want something to be bit off by the larger Python community, we need an answer for this. Answering myself with the kind of navel-gazing which is sure to drive Tres nuts ;-): - We use the heck out of indirections during unit testing. In most of the apps I write personally, the ZCA indirections are the only thing that make it *possible* to write unit tests rather than needing to write functional tests. But typically during testing the idea that some *adapter* is registered against more than one requires interface is just something that we deal with rather something that is actively desirable (because we always only have one implementation during unit testing); the actual multidispatch is to support the below case. - We use adaptation and utility indirections in applications to allow people to override implementations without needing to change the code. Most non-Zope people associate this desire to provide pluggability, correctly or incorrectly, with CMS systems. But there's something to this conclusion because indeed the ZCA indirections were originally meant to replace use of something like acquisition to find values in content space. I suspect we are quite brainwashed here, or at least incapable of discounting this use case, because we tend to treat every application as something that might turn into a framework. - We use utility indirections (or at least I do) to retrieve application-specific configuration values (e.g. BFG's ISettings utility, which offers no behavior except as a bag-of-names). I have some ideas about how you might layer several systems together to allow people to only bite off one bit of software for each of these cases. #2 is the most problematic and would be at a higher layer. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.plugin documentation
Hey, On Mon, Apr 27, 2009 at 6:19 AM, Malthe Borch mbo...@gmail.com wrote: I realize this documentation[1] is still in progress; yet, here are some comments, posted to the list to maybe encourage some kind of debate (since it's likely that there will be several consumers of this package in repoze.* in the future: I find the introduction lacking; why do I care about indirection, what's the benefit. Next, I can't read through the documentation if it's going to be all a and somecomponent; can we have some kind of context, e.g. a story-line or some likely scenario. This would help a lot in motivating the package in the first place, too. Yeah, some times I happen to try to explain things in terms of a and b and soon I realize it wasn't effective. What I *think* it would be more effective in first place is *why* people should write apps that one can extend by layering other components on top of it rather than monkey patching or doing all sorts of incantations to achieve what they want. The spelling is important so people can understand how to implement their story (if they know the so called AOP) by using a given package. repoze.plugin just happen to make it easier to associate the concepts of AOP to the code and maybe attract more people. Cool package after all . Fernando ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
