[ZPT] Re: Path Interpolation

[KevinL]

On Tue, 2002-08-06 at 22:18, Jim Fulton wrote:
> Do we have anyt use cases where people *really* want the value of an
> interpolated variable to be treated as a path expression? I can't
> think of any.

We have a billing system for ISPs we've been working on/selling, and it
includes skin support.  Skin support is done by use of metal macros - we
refer to "here/skins/?skin/pagelayout/macros/std" to get the pagelayout
macro.  ?skin is a variable set by a call to
tal:define="skin here/getSkin" before-hand.

Skins are assigned based on which page the user is viewing, what IP
number they're viewing the page from (location-based skins, for wireless
access points), what browser they're using, and potentially what plan
they're on or other things.  So we have code in the python product that
looks at a database with all those items, to see which skin to use.

If ?skin can only be a single element, then each skin needs to be in a
separate directory in the same place - ie. skins/hilton,
skins/hilton_pda, skins/hilton_plan9, etc.  However, if ?skins can
resolve to multiple elements, then we can dump the pda-specific skin,
the plan9-specific skin, etc, etc under the "hilton" directory - skin
directory structure then becomes:

skins/
  hilton/
    pda/
    plan9
  airport/
    pda/

and so on.  Thus, sub-skins can inherit from the top-level skin, and
clients can change only those files they have to change, rather than
taking a complete copy of the skin into a separate non-inheriting
directory.  Also means our direct customer can, for example, hand
control of the "hilton" directory over to the appropriate people, and
they can futz with whatever sub-skins they want to their heart's
content, rather than having to go through a central person to add a new
skin dir etc.

(Also, this is pretty for end-users to edit, rather than having to
descend to python: calls in the metal statement, which tends to confuse
the punters)

Is that a reasonable use-case?

KevinL