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

[Joachim Durchholz]

Patrick R. Michaud wrote:
> On Fri, Apr 08, 2005 at 10:52:10PM +0200, Joachim Durchholz wrote:
> 
>>>>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!
> 
> There's a difference here -- I'm not forcing a skin writer to do it
> this way.  If a simple list that can be styled is all that is needed
> (as it will be for most of the cases), then the skin writer doesn't
> need regexps at all.

Agreed for the initial barrier.

Minor problem: it's a steeper learning curve. Slice&dice requires 
getting a nontrivial regex right.

Major problem: Most skin writers aren't going to get the regex really 
right. They will miss making the regex nongreedy, or overlook some rare 
borderline case.

Now the real problem: Say the action page looks like this:

||[[action 1]]||
||[[action 2]]||
||[[action 3]]||
...

The skin author has no way of knowing what he's supposed to parse. The 
wiki admin would have to override the parse function in some way, making 
things even more complicated.

Another "supposed to parse" problem is how to differentiate between 
"wrapper" and "separator" elements. Say if the structure is

[[action 1]] * [[action2]] * [[action3]]

the behaviour would be rather different depending on whether action1, 
action2, or action3 is to be sliced away. For action1, it would have to 
be the following *, for action 2, the code is free to slice the 
preceding or the following *, for action3, it *must* be the preceding *.

> And there's nothing to stop someone nice from writing a
> 
>     <!--function:JosActionHandler pre="<start>" sep=" ~ " end="<end>"-->
> 
> that will do it for the skin writer.  :-)

Well, I'm not too good at writing regex parsers...

>>I'd find it definitely simpler to ask him to insert a special "actions 
>>go here" markup in the proper place.
> 
>     $ActionListFmt
> 
> looks pretty darn simple to me.

If that's a proposed new variable: well, I'd like to do it that way, but 
it wouldn't scale to the more advanced scenarios.

>>>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, 
> 
> It's not only unlikely to happen, it's illegal HTML.  The "<a>"
> in the title attribute has to be coded as "&gt;a&lt;" .

Nope, it's perfectly legal. I checked it late night yesterday on 
w3c.org. (I can provide the code tomorrow, when I get back to the 
machine where the example code lives.)

> But the regexp I provided earlier would *still* capture
> your example perfectly.

Well, right, that's because I wasn't devious enough to trigger the bug.

Try this:

php4 -a
<?php
preg_match_all(
   "/<a\\s.*?<\\/a>/is",
   '<a href="1" title="</a>">X</a>',
    $anchors);
var_dump($anchors);

It's ending with the </a> in the title= attribute.

Trying to parse full HTML is difficult enough, but with a regex there's 
always one or the other borderline case. I wouldn't want to do that.

>>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.
> 
> The regexp I provided already handles this just fine.

Well, let's agree you're something of a regex expert :-)

I'm pretty sure that most skin designers won't get the regex right on 
first attempt. Particularly if they have to modify the regex (say, to 
cover constructions like "<tr><td><a .../a></td></tr>"); they'd overlook 
case insensitivity, or greediness, or the potential for attributes; 
they'd have to parse comments (which means that they'd have to skip any 
<a href.../a> within a comment).

Parsing is always far more difficult than constructing. A parse must 
painstakingly reconstruct the structure that's already known in a 
constructor.

>>I could imagine stuff like
>>
>>  ConfigureAction('edit', 'Edit Page');
>>  ConfigureAction('print', 'Printable View', 'target="_blank"');
> 
> I can't.  We would have to provide a bewildering array of options
> and arguments to the recipe writer or wiki administrator, and
> neither one is going to have a clue what is output at the end.

Nobody is interested how the HTML looks like if it works as intended.

Yes, it would be a large array of options and arguments. However, the 
wiki admin can pick exactly those that are of interest to him, and 
safely ignore the rest.

(Compare that with the slice&dice approach, where the skin writer must 
be prepared to face *anything* that wiki admins and recipe writers will 
throw at him.)

>>>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...
>>:-)))
> 
> No, the difference is that with <!--function:ActionXxx--> and an
> array we're putting the learning curve and extra work on wiki 
> administrators (a larger, less capable group), while with 
> slice&dice we're putting the burden only those few skin designers 
> who want to publish skins with fancy action formatting or shared 
> actions across multiple skins.

I think the burden placed on skin designers it too much. (We had some 
reactions in that direction already.)

I agree it is some extra work. But it's a very slight burden, not worse 
than what we're already requesting of them. And the learning curve is 
really shallow, and none of the extra bits and pieces are very complicated.

Well, I think my personal roadmap is clear now. It is:
* look into any available skins and collect the variation needed
* provide the ActionXxx functions
* provide the ConfigureAction function
* write some nice, incremental docs for all concerned parties
   (recipe writers, skin writers, wiki admins)
* include notes where the design is kept variable
   (for example, it's not clear to me whether it's better to
   create action links in wiki syntax or in HTML - I see a lot
   of desire to write them in wiki syntax, but I'm not sure that
   wiki syntax can already express everything that one might want
   on an action link)

It may take a while - other things have been piling up on my desk.

Regards,
Jo