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

Patrick R. Michaud pmichaud at pobox.com
Sun Apr 10 09:03:16 CDT 2005


On Sat, Apr 09, 2005 at 01:28:14PM +0200, Joachim Durchholz wrote:
> 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.

The skin author still just grabs the <a> tags (after the above has
been converted from wiki markup into HTML).  It's the same regex I gave
earlier.

> Another "supposed to parse" problem is how to differentiate between 
> "wrapper" and "separator" elements. Say if the structure is
> [[action 1]] * [[action2]] * [[action3]]

The skin author still just grabs the <a> tags (after the above has
been converted from wiki markup into HTML).  It's the same regex I gave
earlier.  We're assuming that the admin is specifying a list of
action >links< that the skin wants to reformat into a different
HTML structure.

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

This is exactly what I proposed in my post introducing slice&dice --
see http://pmichaud.com/pipermail/pmwiki-users/2005-April/012151.html .


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

Oops, you're right, it's legal.  I was misreading the HTML 4 specification,
which says (http://www.w3.org/TR/html4/charset.html#h-5.3.2)

    Similarly, authors should use "&gt;" (ASCII decimal 62) in text 
    instead of ">" to avoid problems with older user agents that 
    incorrectly perceive this as the end of a tag (tag close delimiter) 
    when it appears in quoted attribute values.

Regardless, it's rare.

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

I'm perfectly willing to let this extremely rare case trigger a bug,
especially since there's a simple workaround.  Or, saying that we
should let the rare cases drive us into more complex implementations
is incorrect -- it's okay if the rare cases are hard(er) to solve
if the common cases are easy.

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

If all we want to do is extract the anchors, then why do we have to
parse out table structures?  I don't get it.  And parsing comments
is again another very rare case (which I doubt has occurred in real
application).  If a simple solution works for 98% of the cases, I'm
perfectly willing to let the 2% odd cases have to work harder.

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

How does a wiki admin know exactly which ones are safe to ignore?
And since the data structure doesn't look like HTML (which the admin
is somewhat familiar with), how does the wiki admin know which options
are supported versus which are not?

Wiki admins are very interested in what the HTML looks like
when he/she can't get things to work as they intend.  If everything
works perfectly the first time, then yes, there's no problem, but
coding web pages is often a lot of trial and error and figuring out
what the HTML is telling the browser to do.  One is almost forced
to care what the HTML looks like -- that's the nature of the beast.

Pm



More information about the pmwiki-users mailing list