103 lines
4.9 KiB
Markdown
103 lines
4.9 KiB
Markdown
I'd like to see some way to conditionally include wiki text based on
|
|
whether the wiki enables or disables certain features. For example,
|
|
[[helponformatting]], could use `\[[if (enabled smiley) """Also, because
|
|
this wiki has the smiley plugin enabled, you can insert \[[smileys]] and
|
|
some other useful symbols."""]]`, and a standard template for [[plugins]]
|
|
pages could check for the given plugin name to print "enabled" or
|
|
"disabled".
|
|
|
|
Some potentially useful conditionals:
|
|
|
|
* `enabled pluginname`
|
|
* `disabled pluginname`
|
|
* `any pagespec`: true if any of the pages in the [[PageSpec]] exist
|
|
* `all pagespec`: true if all of the pages in the [[PageSpec]] exist
|
|
* `no pagespec` or `none pagespec`: true if none of the pages in the [[PageSpec]] exist
|
|
* `thispage pagespec`: true if pagespec includes the page getting rendered (possibly one including the page with this content on it).
|
|
* `sourcepage pagespec`: true if pagespec includes the page corresponding to the file actually containing this content, rather than a page including it.
|
|
* `included`: true if included on another page, via [[plugins/inline]], [[plugins/sidebar]], [[plugins/contrib/navbar]], etc.
|
|
|
|
You may or may not want to include boolean operations (`and`, `or`, and
|
|
`not`); if you do, you could replace `disabled` with `not enabled`, and `no
|
|
pagespec` or `none pagespec` with `not any pagespec` (but you may want to
|
|
keep the aliases for simplicity anyway). You also may or may not want to
|
|
include an `else` clause; if so, you could label the text used if true as
|
|
`then`.
|
|
|
|
Syntax could vary greatly here, both for the [[PreprocessorDirective]] and
|
|
for the condition itself.
|
|
|
|
> I think this is a good thing to consider, although conditionals tend to
|
|
> make everything a lot more complicated, so I also want to KISS, and not
|
|
> use too many of them.
|
|
>
|
|
> I'd probably implement this using the same method as pagespecs, so 'and',
|
|
> 'or', '!', and paren groupings work.
|
|
>
|
|
> It could be thought of as simply testing to see if a pagespec matches
|
|
> anything, using a slightly expanded syntax for the pagespec, which would
|
|
> also allow testing for things like link(somepage),
|
|
> created_before(somepage), etc.
|
|
>
|
|
> That also gives us your "any pagespec" for free: "page or page or page".
|
|
> And for "all pagespec", you can do "page and page and page".
|
|
>
|
|
> For plugins testing, maybe just use "enabled(name)"?
|
|
>
|
|
> I'm not sure what the use cases are for thispage, sourcepage, and
|
|
> included. I don't know if the included test is even doable. I'd be
|
|
> inclined to not bother with these three unless there are use cases I'm
|
|
> not seeing.
|
|
>
|
|
> As to the syntax, to fit it into standard preprocessor syntax, it would
|
|
> need to look something like this:
|
|
>
|
|
> \[[if test="enabled(smiley)" """foo"""]]
|
|
>
|
|
> --[[Joey]]
|
|
|
|
>> [[PageSpec]] syntax seems perfect, and your proposed syntax for the `if`
|
|
>> [[PreprocessorDirective]] looks fine to me.
|
|
>>
|
|
>> [[PageSpec]]s don't give you `none` for free, since `!foo/*` as a boolean
|
|
>> would mean "does any page not matching `foo/*` exist", not "does `foo/*`
|
|
>> match nothing"; however, I don't really care much about `none`, since I
|
|
>> just threw it in while brainstorming, and I don't know any compelling use
|
|
>> cases for it.
|
|
>>
|
|
>> `enabled(pluginname)` will work perfectly, and `!enabled(pluginname)`
|
|
>> makes `disabled` unnecessary.
|
|
>>
|
|
>> A few use cases for `included`, which I would really like to see:
|
|
>>
|
|
>> * On the sidebar page, you could say something like \[[if test="!included"
|
|
>> """This page, without this help message, appears as a sidebar on all
|
|
>> pages."""]]. The help text would then only appear on the sidebar page
|
|
>> itself, not the sidebar included on all pages.
|
|
>>
|
|
>> * On [[blog]] entries, you could use `included` to implement a cut.
|
|
>> (Please don't take that as an argument against. :) ) For instance, you
|
|
>> could use included rather than [[plugins/toggle]] for the detailed
|
|
>> changelogs of ikiwiki, or to embed an image as a link in the feed rather
|
|
>> than an embedded image.
|
|
>>
|
|
>> Some use cases for `thispage`:
|
|
>>
|
|
>> * You could use `thispage` to include or exclude parts of the sidebar based
|
|
>> on the page you include it in. You can already use subpages/sidebar for
|
|
>> subpages/*, but `thispage` seems more flexible, makes it trivial to have
|
|
>> common portions rather than using [[plugins/inline]] with the `raw`
|
|
>> option, and keeps the sidebar in one place.
|
|
>>
|
|
>> * You could use `thispage` to implement multiple different feeds for the
|
|
>> same content with slightly different presentation. For instance, using
|
|
>> templates for image inclusion, you could offer a feed with image links
|
|
>> and a feed with embedded images. Similarly, using templates for cuts, you
|
|
>> could offer a feed with cuts and a feed with full content in every post.
|
|
>>
|
|
>> I don't have any particular attachment to `sourcepage`. It only makes
|
|
>> sense as part of a template, since otherwise you know the source page when
|
|
>> typing in the if.
|
|
>>
|
|
>> --[[JoshTriplett]]
|