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

[Patrick R. Michaud]

On Fri, Apr 08, 2005 at 07:55:41PM +0200, Joachim Durchholz wrote:
> Agreed.
> 
> >and the best place for that to happen is generally in the skin and 
> >not in PHP code.  But that's just my opinion.
> 
> It must happen in PHP, at least partly. After all, the visibility of 
> each action link should be controllable from PHP, to facilitate making 
> action links invisible depending on who logged in.

Well, sure, but just because it should be controllable from PHP
doesn't mean it *has* to be there.  We can also do login-based-visibility
via wiki markup or CSS, to name just two other possibilities.  I'd
prefer to have a solution that allows for all three.

> Now I've seen the slice&dice concept. It made my head hurt: the regex 
> was inscrutable, and I was imagining the skin author who tried to 
> determine whether his all-new way of writing action links would be 
> recognized by the slice&dice function. (If he was aware of that function 
> in the first place...)

No, the idea is that the skin author would write his own slice&dice
function to extract the links based on the <a> tags, then put them
together in his all-new way of formatting action links.  That's all
there is to it.

> I also see all sorts of bugs creeping in whenever PmWiki changes its 
> idea about how action links are displayed. That slice&dice thing 
> essentially needs to parse a large subset of HTML, and I don't think 
> that regexes can do that. 

No, it just needs to parse <a> tags, which is easy, and PmWiki 
isn't likely to get rid of those.

> Not to mention unexpected interactions with 
> substitutions that come before or after it.

Functions in skins are always called *after* all substitutions
have taken place.

> Agreed, but currently PmWiki makes no attempt at making the 
> invisible-but-available actions discoverable. Not in the UI itself, at 
> least (and I have been finding that quite annoying - I don't want to dig 
> through documentation just to discover yet another action, I'd really 
> prefer to have an "expert mode" or "explorative mode" that shows me all 
> actions available to me, useful or not).

Fair enough.  But this capability probably doesn't belong in skins,
then.  Better would be to provide ?action=listactions, which just 
displays the available actions as given by the $HandleActions array.
Or we could create (:listactions:) markup, which does the same thing.

> >So, it's entirely reasonable (and desirable) to have actions that 
> >visible but inaccessible, or actions that are accessible but invisible.
> 
> Agreed.
> 
> But then the site admin should decide which action goes to what 
> category. Not the skin author (though it's well conceivable that the 
> skin author gives recommendations).

This is exactly what I've been saying all along, along with the
fact that site admins are normally not PHP experts, so we shouldn't
expect or ask them to be able to parse/configure deep PHP arrays.

> I wanted to continue to write something like "however, this isn't a 
> problem if the actions are the standard ones like 'read' and 'edit'". 
> Then I reconsidered: it *is* a problem. There is no such thing as a 
> standard action. 

Bingo.

> The slice&dice approach would properly take care of that. I'd prefer it 
> if I saw a chance that it could work silently and effortlessly. It's 
> just that I have too many instances of slice&dice either not work at 
> all, or become cruft within a matter of weeks.

I think you're just misunderstanding the slice-and-dice
algorithm I put together (which is just a template for skin
designers).  Shall I walk through it?  It's really not that
complex or difficult, and again, only skin authors that want to
modify the actions beyond simple lists would ever have to write
something like it.  It can even be made to easily handle
"primary" and "secondary" actions.  The nice thing about it
is that we don't have to decide in advance what all of the possible
link permutations are going to be.

Pm