On May 5, 2008, at 1:42 PM, Ian Bicking wrote:

> OK, so I feel okay about a redesign of selectors and rules.  So the  
> other thing is selecting themes and whatnot.
>
> I still like the idea of using names and indirection, ala CSS  
> classes. I'm thinking of calling them page-class, like "page type"  
> that Wichert suggested, but using "class" to suggest that a page  
> isn't exclusively one thing.

I still worry that Deliverance is growing concepts and capabilities  
beyond its original intent.  However, I'll yield on this point, as I  
believe most want to see this at least explored.

Just to see if I have the big picture right:

1) We have a need to define a bunch of matching conditions, as well as  
actions to take when those matches occur.

2) We plan to separate the definition of the scenario matches from the  
definition of actions.

3) The former are called "page classes".  These page classes put a  
label on when a scenario is matched.

4) The latter are "rule sets".

5) There is somewhat of an N:N relationship between scenarios and rule  
sets.  A rule set can point to multiple page classes.  A scenario can  
trigger rules from multiple rule sets.

Am I in the ballpark?

> The obvious and explicit way to set the class is with X-Deliverance- 
> Page-Class, either an HTTP header or <meta http-equiv>.
>
> Setting these isn't always easy.  You have to poke around in  
> templates to do it, and for something like styling Trac it would be  
> nice to do it completely externally to Trac itself.  So back to path  
> matching.  This seems fairly obvious:
>
>  <match path="/foo" class="foo" />
>
> There will be the <match> tag, and these selectors as attributes:
>
>  path: a path.  If it allows wildcards, I am a little concerned  
> about people mistakenly putting an exact path and assuming it is a  
> prefix.  So I'm thinking this won't take wildcards.  A trailing /  
> won't matter -- /foo/ and /foo will be treated equivalently, and  
> neither would match /foobar.
>
>    Perhaps prefixes could allow different kinds of matches.  E.g.:  
> "wildcard:*/manage*" or "regex:/wp-admin/(post|new-post)\.php".
>
>    I'd like a way to indicate whether just PATH_INFO or the full  
> path is being matched.  People are naturally inclined to view it as  
> a full-path match.  Perhaps a leading / would indicate this, and no  
> leading / means match SCRIPT_NAME.  Except that wouldn't work for  
> wildcard and regex matches.  For most installations PATH_INFO will  
> be the full path, so it's a little academic.  But that's not true  
> for openplans, so I have to think about this.

I'll be interested to see what you come up with.

At the same time, I'd like to go ahead and work up some science  
fiction and a super-basic prototype, just so we know we all agree on  
the basic concepts.  So perhaps we defer this PATH_INFO/SCRIPT_NAME  
for now.

>  domain: a domain, with possible wildcard.

For Deliverance running as a proxy, Is this the forward domain or  
reverse domain?

>  request-header: this would be "Header: match", like "X-Requested- 
> With:  regex:(?i)xmlhttprequest".  The header name will be parsed  
> out.  Maybe allow wildcards?  The part after : will be matched like  
> path, except maybe a case-insensitive whitespace-normalized match as  
> the default.  So "X-Requested-With: xmlhttprequest" would match a  
> value of "XMLHttpRequest", but wouldn't match "XMLHttpRequest/foo"
>
>  response-header: just like request header, but the response.

I wonder if query string would need to be a match type.  This would  
allow solving ?notheme as part of the general case.

>  last: if this is "1", then if this <match> matches, no other  
> matches will be checked.  (Not sure if this is the best name... it's  
> like [L] in a rewrite rule)
>
> If you provide multiple attributes then they all must match.  I'm  
> not sure how to allow multiple attributes of the same type, like if  
> you want to match multiple request headers.

While I know these questions are important, they also hurt my brain,  
so I'll ignore it. [wink]  (This line, and the cumulative part next,  
was the reason I got stuck so long without replying.)

> Then there's the question: are classes entirely cumulative, like CSS  
> classes?  Or is there a way to suppress a class?  Like class="- 
> standard my-page-type", to remove the standard page type (there  
> might be an implicit <match class="standard" /> rule).  Or maybe  
> last="1" would stop any other classes, and so you've implicitly  
> excluded all other classes from being added if you use it.
>
>
> OK, so then the actual rules.  We introduce a single attribute:
>
>  <rules class="class_name(s)">
>    <append ... />
>  </rules>
>
> Except... we've already used <rules>.  We could use <class  
> name="class_name">, but I would kind of prefer that the attribute  
> name be "class" in both the match and rules.
>
> Maybe better than things like -standard, would be a way of including  
> other classes in a rule.  Like:
>
>  <rules class="my-page">
>    <match class="standard" />
>  </rules>

How about supporting a simple version and a complex version:

<rules match="my-page">
   rule1
   rule2
</rules>

...for the simple case and:

<rules>
   <match>my-page</match>
   <match>your-page</match>
   <match>another-page</match>
</rules>

...for the complex case.

I'm really hoping that people don't have multiple-page-class-matching  
scenarios until they are way, way, WAY into the koolaid.

> then this would also have any standard rules.  This kind of  
> overloads <match>, though I think in a way that's reasonably  
> intuitive -- it feels the same, even though the implementation would  
> be quite different. Though I'm not inclined to allow any other  
> conditionals like <match path="..." /> in this context.
>
> Also, <theme href="..." /> would be allowed in this context, and the  
> first matched class (I'd maintain classes in an order) would have  
> its theme used.

<theme> is a child of what?  The N:N part has left me a bit bumfuzzled.

--Paul