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
