[pmwiki-users] Feature request: Action lists in skins

Mon Apr 18 10:57:48 CDT 2005

On Mon, Apr 18, 2005 at 09:55:05AM +0200, Joachim Durchholz wrote:
> 
> >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's markup handling.) It's a registry of markups.
> [...]
> 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.

It's important to match the sophistication level of the registry to the
target audience.  This is partially why PmWiki has several different
registries -- the complexity of the registry is targeted to the
level of person who is likely to use or need it.

I'm gathering action lists need a high degree of customization on
individual sites, so wiki pages make much more sense here.  This is
similar to what we encountered with internationalization; originally 
I had all of the translation code held in arrays and set from PHP.  
However, it quickly became obvious that any i18n work was therefore 
limited to people who understood all of (1) the target foreign 
language, (2) PHP, and (3) PmWiki's array handling.  Sharing 
translation recipes also was a pain.  As a result, I switched over 
to the current XLPage design where the strings are customized via a 
wiki page, and as a result we get far more language translation and 
cross-compatibility than the previous array-based design could ever supply.

> >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
> (XLPage("de");).
> 
> Setting up action lists should not be more difficult. Modifying the way
> that existing actions works either.

Action lists *are* more difficult simply because the number of
parameters and options involved.

> >So, does anyone know how to assign classes and ids to elements with
> >wiki markup?
> 
> 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. 

Actually, it *is* relatively easy:

   Markup('css', 'directives',
     '/\\(:css (\\.\\w+\\s+\\{[^}]*\\})\\s*:\\)/e',
     "PZZ(\$GLOBALS['HTMLStylesFmt'][] = PSS(' $1 '))");

enables

   (:css .someclass { color:green; } :)

and produces ".someclass { color:green; }" in the <head> section of
the document.  See http://www.pmwiki.org/wiki/Test/CSSMarkup .

> 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? 

Indeed, this is one reason I haven't made it standard in PmWiki.
(The other reason is that I'm not certain what it should be called.)

> Should the 
> class/id assignment markup be restricted to certain wiki pages? (This 
> would be the first wiki markup restriction.) 

I'm not sure what you mean by "the first wiki markup restriction".

Pm