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

[Joachim Durchholz]

Hans wrote:

> On Mon, Apr 04, 2005 at 01:43:43PM +0200, Joachim Durchholz wrote:
> 
>>So it would be best to have the skin just specify where the action list
>>should go, but not specify the actions themselves.
> 
> I have done this in the design of GeminiTwo and FixFlow skins by
> putting the actions into wiki pages: PageTopMenu and PageFootMenu.
> These get inserted into the skin template via
>   <!--PageTopMenuFmt-->
>     <div id='topnav'><!--wiki:$Group.PageTopMenu Main.PageTopMenu--></div>
>   <!--/PageTopMenuFmt-->
> and
>   <!--PageFootMenuFmt-->
>     <div id='footnav'><!--wiki:$Group.PageFootMenu Main.PageFootMenu--></div>
>   <!--/PageFootMenuFmt-->
> 
> This makes it possible to specify the actions as unordered lists of
> links independent from the skin template, in an easy way by the
> user and not necessarily the administrator, and customizable for
> groups if wanted.

Ah, that's an option that I hadn't thought off. Definitely a line worth 
pursuing.

> To summarize advantages and disadvantages:
> + Skins are simpler to design.
> + Action links are independently defined from the skins.
> + Action links can be defined by users and administrators.
> + Action links can be customized easily on a per group basis.
> + Only relevant action links need to be shown.

Can be done with the proper CSS magic. The HTML for action "foo" would 
look something like this:

<span class="action_foo">
prefix to link (say, <tr><td>)
<a class="action_foo" href="http://.../Group/Page">Do a Foo on Page</a>
postfix to link (say, </td></tr>)
</span>

On top of the page, PmWiki could generate inline CSS for the various cases:

Normal links ->
   don't generate anything special.
Disabled links ->
   .action_foo {display:none}
Current link ->
   span.action_foo {color:grey}
   a.action_foo {active:no} /* or whatever it takes to deactivate <a> */

Actually I see the first problem here: the CSS for disabled links would 
have to specified by the skin. Since we're in CSS land here, trying to 
specify that from within a wiki page is going to give us trouble. (Well, 
yes, the wiki page could always simply list the CSS to be emitted, but 
that's (a) slow and (b) prone to interferences from markup rules.)

Dropping down to PHP for that would be an option. Though that leaves us 
with a configuration that's spread over Wiki (for the contents, i.e. the 
actual selection of actions for a list), CSS (for the layout), and PHP 
(for the logic). I wouldn't object if the three layers were truly 
independent (i.e. changes in one wouldn't require a corresponding change 
in another one), but that's not the case here.


... Oh, I just see a potential simplification for the above HTML. It's 
enough to say

<span class="action_foo">
prefix to link (say, <tr><td>)
<a href="http://.../Group/Page">Do a Foo on Page</a>
postfix to link (say, </td></tr>)
</span>

The "current link" CSS then looks like this:
   .action_foo {...}
   .action_foo a {...}

One less <span> needed.

> + Custom links can be easily included.
> + Clear separation from design and content.

Almost, unfortunately. After all, one of the things that a skin controls 
is the layout of the action links (horizontal vs. vertical row, 
delimiters between links, whatever).

When changing from a skin designed for a horizontal row to one designed 
for a vertical one, you'd have to go through all the action list pages 
and adapt them so that things look good again.

> + Skin installation is easy if default menu definition pages are
>   included in wikilib.d as standard, just as there is a standard
>   SideBar page included.
> - Skin installation is more complicated if default menu definition
>   pages are not included in wikilib.d, since they have to be
>   created separately.

Having a Wiki page to add the new action is certainly easier on 
administrators.

I see two potential problems here:

1) I'd like it if a new module automatically installed any new actions. 
Not in a group header (that's a no-no: if a wiki admin is experienced 
enough to set up group-specific action lists, he'll already have some 
quite precise ideas what groups would get those new actions), but at 
least in Main (that's for the inexperienced wiki admin: he'll at least 
see that his new action got installed successfully, and he immediately 
has a link to try the thing out).
This might be done in a fashion analogous to the WikiTrail stuff. I feel 
rather uneasy about that approach though - lots of ways that mucked-up 
markup can disable an action. On the positive side, installing a markup 
would amount to nothing more complicated than adding a "* 
new-action-code New action text" line at the end of the page. (Provided 
that there's a function that can add a line to an existing wiki page.)

2) It's quite easy to lock yourself out with that approach. This is a 
danger especially for those wiki administrators who do their first 
experiments with action lists.
This problem can be mitigated by placing heavy warnings on the 
corresponding documentation page, and giving the hint that they should 
do their first experiments in the WikiSandbox group. And by giving the 
hint that they can add arbitrary actions by appending "?action=whatever" 
to the URL input field, so if they do "?action=history" on the 
ActionList topic they can always revert to a known working revision.

Regards,
Jo