Revision [2793]
This is an old revision of ValidPageNames made by DarTar on 2004-12-03 11:02:43.
Pagename validation and link formatters
I open this page to discuss problems related to pagename validation and the underlying regex that are needed to validate and format both camelcase and forced links.
Current pattern for valid pagetags
$validtag = "/^[A-Z,a-z,ÄÖÜ,ßäöü]+[A-Z,a-z,0-9,ÄÖÜ,ßäöü]*$/s";
Some considerations off the cuff:
- The German eszed (ß) can't appear at the beginning of a word in any language, so we might drop it from the first character class.
- If we are to allow accented characters in valid page tags (are we?), we should consider allowing also other characters like for instance èéêëñç that are part of the extended ASCII charset (iso-8859-1).
- We should prevent non-escaped URIs to be parsed as pagetags or at least encode them before applying a validator: http://wikka.jsnx.com/ÄrgerMich is correctly encoded, but what if a user pastes this URL directly in the address field of a browser?
Apart from a possible "German" origin, I never understood the bias here to allowing German characters but not non-ASCII characters used in other languages. That said, I don't think an RE should look for a "word" but merely a "string-consisting-of-letters-and-digits-and-starting-with-a-letter". By using a hex encoding inside the RE for "letters" we would also make this encoding-independent, thus not limiting to ISO-8859-1 (why not a Turkish Wiki with Turkish page (and user) names?).
I don't know, I'm a little uncomfortable with the idea of allowing any kind of character in a WikiName. AndreaRossato pointed out that a Pagetag and a WikiName should only contain ASCII characters. The question of pagenames in different charsets cannot be addressed IMO without taking some decisions concerning multilanguage support and UTF-8 encoding. Or am I misunderstanding your proposal? -- DarTar
Also, the commas in that RE are puzzling - do we allow a Wiki name to start with or contain a comma? I think not - and in that case they should go.
Another thing I find a bit strange is that this RE requires that a tag starts with two letters, and may be followed by any number of letters and digits - why not start with a single letter and require at least two alphanumeric characters?
Building on that, let's first set up some RE building blocks:
define('PATTERN_LCLETTER', 'a-z\xdf-\xf6\xf8-\xff');
define('PATTERN_UCLETTER', 'A-Z\xc0-\xd6\xd8-\xdf');
define('PATTERN_LETTER', PATTERN_LCLETTER.PATTERN_UCLETTER);
define('PATTERN_DIGIT', '0-9');
define('PATTERN_UCLETTER', 'A-Z\xc0-\xd6\xd8-\xdf');
define('PATTERN_LETTER', PATTERN_LCLETTER.PATTERN_UCLETTER);
define('PATTERN_DIGIT', '0-9');
Now we can use those to build an expression for a valid tag:
$validtag = '/^['.PATTERN_LETTER.']['.PATTERN_LETTER.PATTERN_DIGIT.']+$/';
Note I've also discarded the 's' modifier: if we need to match something that is a string without any whitespace, we don't need to treat multiple lines as a single one.Current pattern for valid usernames
JavaWoman pointed out that Wikka currently restricts valid usernames to camelcase-formatted WikiName WikiNames. Is this consistent with the fact that we actually do allow valid pagetags in forced links beyond the camelcase format? And what about special characters in usernames?
- DarTar is an allowed username and it is correctly parsed as a link.
- SchönesMädchen is an allowed username (you can actually register with this name) and is parsed as a link, also if you force it as [[SchönesMädchen]]: SchönesMädchen .
- Because of the currently used validation pattern, French users are discriminated while German users aren't :) - SchönesMädchen is allowed (with the above restrictions) while BelleFrançaise or NiñaHermosa aren't (look BTW at the incorrect WikiName segmentation produced by the cedille). On the other hand, they produce inconsistent links if you force them as [[BelleFrançaise]] and [[NiñaHermosa]]: BelleFrançaise NiñaHermosa). This should be IMO fixed as soon as possible.
Using the patterns outlined above should fix this. :) --JavaWoman
A better formatter for forced internal links
I think that the current forced link formatter should be improved to allow GET parameters, anchors and titles to be parsed as part of valid internal links.
For example it would be nice if we could not only use forced links like:
[[HomePage Internal forced link]]
or
[[http://www.google.com External forced link]]
but also the following:- Forced internal link with URL parameter
[[HomePage (? "par1=ba,par2=bo") Internal forced link]]
- Forced internal link with anchor
[[HomePage (# "this") Internal forced link]]
=> http://wikka.jsnx.com/HomePage#this
- Forced internal link with Title
[[HomePage (§ "This is a link to the HomePage") Internal forced link]]
But I don't have a clue on how to modify the current formatter to send to the Link() function all this stuff.
I like this idea very much, especially being able to add a title. A few remarks, no particular order:
- The paragraph sign § is not present on many keyboards (though probably on yours); I propose to use an exclamation mark instead.
- Good point --DarTar
- Adding a title would also be usefult for (forced) external links, not just internal ones; could use teh same syntax, of course.
- Good point as well --DarTar
- How to combine these various options? Each in a separate pair of brackets, all in a single pair of brackets together? I have a preference for the latter but haven't looked at any implications for the Formatter yet.
- To combine query parameters they should be separated with &, not a single & which is invalid in HTML
--JavaWoman
- This has to be done by the formatter, not by the user. -- DarTar
-- DarTar
CategoryDevelopment CategoryRegex
