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

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

Reply via email to