an existing wishlist item.
> I think it would make sense to have "pagespec" in the name somehow.
+
+> > Good idea, how about `pagespecalias`? — [[Jon]]
+
>
> No, the strict/warnings does not make me puke. Have you read my perl
> code? :-P
> Well, except that websetup doesn't currently support configuring hashes
> like used here. Which is a pity, but has led me to try to avoid using
> such hashes in the setup file.
->
+
+> > If I removed the `getsetup` subroutine, it would not be exposed via
+> > website, is that right? I suppose it doesn't hurt to validate key, even if
+> > this risk was not there. Is the use of a hash here a blocker for adoption?
+> > — [[Jon]]
+
> Have you considered not defining the pagespec aliases in the setup file, but
> instead as directives on pages in the wiki? Using pagestate could store
> up the aliases that have been defined. It could however, be hard to get
> an alias `foo` would need to somehow depend on the page where the alias
> was defined. --[[Joey]]
+> > I haven't thought the dependency issue through beyond "that might be hard".
+> > Personally, I don't like defining stuff like this in pages, but I appreciate
+> > some do. There could be some complex scenarios where some pages rely on a
+> > pagespec alias defined on others; and could have their meanings changed by
+> > changing the definition. A user might have permission to edit a page with a
+> > definition on it but not on the pages that use it, and similar subtle permission
+> > bugs. I'm also not sure what the failure mode is if someone redefines an alias,
+> > and whether there'd be an unpredictable precedence problem.
+> > How about both methods? — [[Jon]]
+
Here's an example setup chunk:
pagespec_aliases:
> Probably needs to be `or internal(*)` --[[Joey]]
+> > Ah yes, could be, thanks. — [[Jon]]
+
> another useful pagespec alias for large maps:
basewiki: "sandbox or templates or templates/* or ikiwiki or ikiwiki/* or shortcuts or recentchanges or wikiicons/*"
Unfortunately I haven't figured out how to do the dependencies - I'd really appreciate help on that.
--[[KathrynAndersen]]
+
+> > Cool! I like the caching idea. I'm not sure about the name. I don't like defining
+> > stuff in pages, but I appreciate this is a matter of taste, and would be happy with
+> > supporting both. — [[Jon]]
+
+>>> I've now gone and completely re-done "subset" so that it is less like an alias, but it a bit clearer and simpler:
+>>> instead of having a separate "match_" function for every alias, I simply have one function, "match_subset"
+>>> which takes the name of the subset. Thus a \[[!subset name="foo"...]] would be called `subset(foo)` rather than `foo()`.
+
+>>> There are a few reasons for this:<br/>
+>>> (a) it's more secure not to be evaluating code on the fly<br/>
+>>> (b) it's simpler<br/>
+>>> (c) (and this was my main reason) it makes it possible to do caching without having to have a separate "subset" argument.
+>>> I've done a bit of a hack for this: basically, the PageSpec is checked to see if the very start of the PageSpec is `subset(foo) and` or if the whole pagespec is just `subset(foo)` and if either of those is true, then it does the subset caching stuff.
+>>> The reason I check for "and" is that if it is "subset(foo) or something" then it would be an error to use the subset cache in that case.
+>>> The reason I just check the start of the PageSpec is because I don't want to have to do complex parsing of the PageSpec.
+
+>>> As for defining subsets in the config rather than on pages, I perfectly understand that desire, and I could probably add that in.
+
+>>> As for the name "subset"... well, it's even less like an alias now, and "alias" is already a reserved name. What other names would you suggest?
+
+>>>--[[KathrynAndersen]]