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

[Joachim Durchholz]

Patrick R. Michaud wrote:

> On Fri, Apr 08, 2005 at 07:55:41PM +0200, Joachim Durchholz wrote:
> 
>>>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.

Yup, it's essentially the question which mechanism to use to transport 
the decision to CSS.

It's just that the question "where do form and function meet?" doesn't 
really have a useful answer. It's a long transmission chain, with lots 
of places where the decision could take effect.

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

Er... you're asking skin writers to deal with regexps... now I really 
wonder who's asking difficult things of skin writers!

I'd find it definitely simpler to ask him to insert a special "actions 
go here" markup in the proper place.

>>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 easy at all. Try to deal with

  <a href="..." title="This has an <a> tag.">...</a>

Sure, that's unlikely to happen with an action link, but then if the 
skin designer puts stuff into action links for debugging purposes and 
gets bewildering behaviour because his regex parsing doesn't work as 
expected. (People get the weirdest ideas, so I tend to be over-careful 
here...)

For a more realistic example, take with multiple <a href>...</a> links 
on the same line, which runs our poor skin designer into greediness 
issues in no time.

That's just the pitfalls that I can think right off the top of my head. 
I'm sure there are others.

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

Which means that the line will contain text that the skin designer 
doesn't see in the skin. Another potential source of unexpected behavior.
(I'm not sure that there weren't error scenarios if things were the 
other way round.)

... um, well, I just realize that this problem is always there, 
regardless of how one does it.

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

Agreed.

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

Maybe something like ?action=showactions:all. Or 
?action=setactionlist=full. Which would change a setting so that the 
full action list is visible.

The (:listactions:) markup would have its merits, too. Actually it's 
exactly what I've been trying to advocate ;-)))

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

Hmm... I haven't thought of that. I'm too much of a programmer I guess.

But then that's easy to correct. Just provide functions that update the 
array accordingly.

I could imagine stuff like

   ConfigureAction('edit', 'Edit Page');
   ConfigureAction('print', 'Printable View', 'target="_blank"');

That would be used in pmwiki.php before calling config.php, or in 
recipes, so set up the actions initially.

For config.php, there might be a function

   ReconfigureAction($actionId, $aspect, $newvalue)

e.g. like

   ReconfigureAction('edit', 'options', 'target="_blank"');

now that's a silly example, but the site admin could do

   ReconfigureAction('print', 'options', '');

to eliminate the target="_blank" if he doesn't want it.

PHP functions can take variable numbers of arguments, this could be used 
to reconfigure multiple things at once. If the site admin decides that 
the 'edit' and 'history' actions belong to the 'secondary' group after 
all, but 'xref' and 'print' to the first, and also wants to nail down a 
sort order, he can write things like

   ReconfigureAction('xref',    'group' => 'primary',   'sort' => 1);
   ReconfigureAction('print',   'group' => 'primary',   'sort' => 2);

   ReconfigureAction('edit',    'group' => 'secondary', 'sort' => 1);
   ReconfigureAction('history', 'group' => 'secondary', 'sort' => 2);

This certainly doesn't look complicated to me. But them I've got far too 
much CS background to accurately judge that, so I'll leave it to

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

No, not really. I'm pretty sure I could decipher it on my own. The point 
that I wanted to make was that many potential skin writers will run away 
screaming if you throw that regex at them. Heck, it would have made *me* 
run away screaming; I avoid regexes as far as I can even though I'm a 
very tech person and have been living with and using them for more than 
a decade now.

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

Um... I could say just the same about the <!--function:ActionXxx 
approach... actually it's what I *have* said...
:-)))

> It can even be made to easily handle "primary" and "secondary"
> actions.

Again, that holds true for both approaches.

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

Sure. The build-from-details approach can be overly restrictive if not 
done right. I'll have to download all skins and look what kind of 
variation is there, and liberally generalize beyond what I find. (The 
critical part being, of course, the "liberally generalize".)

Regards,
Jo