[pmwiki-users] regex for full page names with anchor suffixes

[Hans]

Thursday, November 8, 2007, 8:08:19 PM, Patrick R. Michaud wrote:

> First, a question:  if it's possible to use a partial pagename,
> how would the system know if "xyz=..." is refering to the option 'xyz'
> or to the page 'Xyz' in the current group?

Well I tried to provide a list of permitted keys. But this is prone to
lead to user input errors, and rather clumsy. So I drop that idea.

> One suggestion I'd have would be to use an explicit syntax
> for pagename specifiers, such as brackets.  I.e.:

>     (:directive  xyz=...   [Group.Abc#section]=... [xyz]=... :)
>.....

I may add this as an option, but I am not too keen on having to insert
brackets. My preferred syntax would be just the following, but allowing
multiples as well:

  (:directive  GroupA.Template#section=>GroupB.Target  abc=... defgh :)

I think it may be okay to demand that any page name is entered with
a Capital first letter, or numeral, and that key names are always starting
with a lower case letter. So the first capital will make the key into
a page name, rather than a parameter key. And any loose parameter
value (without a key) will get special treatment. My whole aim is to
have a shorter syntax, which reads well and can be repeated over a
number of directives.


> If you really want a bare option syntax for pagenames, then
> I suggest keeping the pattern very simple (and possibly permissive)).
> I'll space it out here for clarity:
>...[snip]..

Thanks! This is very helpful! I try to use this now like this, with
the option of using => or = as divider:

$arg = ParseArgs($arg,
'(?>([-\\w]+(?:\.[-\\w]+)?(?:\\w#[-.\\w]*)?(?:\\#[-.\\w]*)?)(?:=>?|:))');

ParseArgs works with it, but the > from the => gets put as first
character to the value, and I have to run it through a "cleaner":

   if(substr($v,0,4)==">") $arg[$k] = substr($v,4);

Can this be avoided? Why is it added? Thanks for help with this!


  ~Hans