[pmwiki-users] Feature request: Action lists in skins
jo at durchholz.org
Mon Apr 18 02:55:05 CDT 2005
Bronwyn Boltwood wrote:
> On 4/17/05, Joachim Durchholz <jo at durchholz.org> wrote:
>> Hmm... how about giving skin designers a way to say "action list #1
>> goes *here*, action list #2 goes *here*", and letting skin
>> designers recommend which kinds of actions should go to what action
>> list? That would allow wiki admins to easily experiment with
>> different action groupings, for example.
> You'd have to give a better example for me to judge properly, but you
> might be making it more complex and less flexible.
I hope not!
> Creating a system that does the right thing for the admin, but is
> still easy to modify, is a big job, and I'm not sure we'd come up
> with anything vastly better than we already have.
I consider decoupling skins from action lists a vast improvement.
Actually I think that skins are currently doing a lot of things that
should be done elsewhere - the work itself is good, but I'd like to be
able to mix-and-match good design ideas with good functionality ideas.
Some skins look great but are too brittle for use, and some skins look
drab but are great "under the hood".
I'd like to be able to judge a skin by its appearance. If that means
"dumbing down" what a skin usually does, then so be it - all that great
functionality that some skins (yours prominently, I might add *g*) offer
could be done in other ways.
> Obviously we could have some elaborate arrangement with a central
> registry of actions, and configuration files, and all that.
PmWiki already *is* a bunch of registries and configuration files!
And that's exactly at the core of PmWiki's flexibility. Want to do
something innovative? Find the right registry and insert the appropriate
configuration string, or write a function and register that. PmWiki will
take care of calling it in the proper context (eliminating a lot of the
stability issues that other wikis have when people add new code).
Technically, PmWiki registries are arrays containing either strings
(format strings and regular expressions), or functions to be called when
the circumstances are right (the sequence of actions called during a
page edit sequence, for example). Some arrays are both: the markup table
notes, for each markup, a regular expression that is used to find the
places in the wiki text where that markup was used, and a function that
is to return the HTML code that's to be generated for the markup. (I'm
skipping a whole lot of technical details here, but that's the core of
PmWiki's markup handling.) It's a registry of markups.
That's highly sophisticated. Yet markup authors don't have much trouble
with that construction: they are happy that writing a new markup doesn't
interact with other markups or the wiki machinery in general, they
simply write a regular expression describing the syntax for their new
markup, and some code that generates HTML from it. The sophistication is
hidden within the Markup() function, which takes just a few parameters
and "does the right things" under the hood.
I'm trying to achieve something similar for action lists.
> But, if Pm could tell me how to add classes or ids to elements
> through the wiki markup, then I think I'd prefer to store the action
> lists and so on in wikipages, because most admins will understand how
> to edit those,
Wiki admins are also able to write simple PHP code: assignments to
configuration strings ($EnablePathInfo = 1), and calls to functions
Setting up action lists should not be more difficult. Modifying the way
that existing actions works either.
I don't think that wiki pages are the right place. Yes, it's tempting to
put all kinds of configuration information in them, and it's a standard
move for the vast majority of wikis. Actually it's unavoidable to do at
least some of that - as soon as user accounts exist and have the profile
pages tied to user accounts, people want to make use of that and store
per-user configuration in their profile pages. That's even OK when it
comes to selecting the skin that the user wants to see, for example.
However, the selection of available actions is critical to the security
of the entire site. It's function, not form - and it should go to PHP.
The black art here is to get the subdivision between function and form
right. To design it in a way that constrains neither skin writers nor
wiki administrators (nor recipe writers who write actions, I might add).
It's an interesting problem, which is why I'm still behind it ;-)
(that's not very different from your interest in skin design, I think -
we both are interested in seeing how far we can take an idea, and how
near to our ideals we can take it).
> and restore the old version if they make a mistake. I'd have done it
> with Pukka except for the classes and ids problem. Then, if the
> default skin uses certain pages to store the actions for the
> titleblock and footer, many other skins will use them too, so the
> admin's configuration won't always disappear upon switching skins.
> But, skin designers can still experiment with the grouping of the
> commands by making their own set of wikipages, and telling the admin
> where they are.
> So, does anyone know how to assign classes and ids to elements with
> wiki markup?
%CSS goes here% ... %% generates a <span>...</span>, so it's nearly what
If you want closer control (e.g. an override for a given CSS class), I
don't think that PmWiki comes with that.
Which doesn't mean that it's impossible. There's always the option of
adding new wiki markup. In this case, it isn't technically easy to
generate the CSS overrides (they should go to the HTML <head> section,
and I suspect it's generated before markups are processed), but it could
be done. The more interesting question is how it should be done. If wiki
authors are allowed to influence the CSS, how do we prevent them from
sabotaging a page by using white script on white background? Should the
class/id assignment markup be restricted to certain wiki pages? (This
would be the first wiki markup restriction.) Say only wiki pages in a
hypothetical Admin group are allowed to use that markup: what should
happen if a page is moved out of that group via a Rename operation?
More information about the pmwiki-users