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.    
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 
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 

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 
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

Reply via email to