[pmwiki-users] Re: newwin with defined size

[Joachim Durchholz]

Christian Schlatter wrote:

>> Since it's bad practice to emit PHP errors if the user mistyped the 
>> markup, I suggest changing the markup so that it will be ignored until 
>> it has at least one parameter, like so:
>>
>>  >> Markup('newwin', 'directives', '/\\(:newwin\s+(.+?):\\)/e',
>>                                               ^^^  ^
>>  >>        "newwin(PSS('$1'))");
>>
>> The \s+ requires a nonempty sequence of blank-space character, and the 
>> + makes the regular expression want at least one character after that 
>> sequence - the net result is that ParseArgs will find at least one 
>> parameter and fill $args[''] with at least one array entry.
> 
> Nice solution, although I think it is still better for an end user to 
> output something like "newwin error: you should define xy" instead of 
> the markup itself.

I have done so in the Input recipe.

I have somewhat mixed feelings about that though. Seeing that the markup 
wasn't recognised usually alerts the wiki author to the problem - and 
even if it doesn't, the next author will be alerted. Emitting error 
messages is somewhat less "friendly".

For Input, it was unavoidable - there are too many different possible 
causes if a markup is erroneous, so simply showing the unprocessed 
markup doesn't give the author a clue what exactly went wrong.

 > BTW, it would be nice to have a global PmWiki error
> handling function, that could be called within markup code. Maybe a 
> function that collects all error messages (classified by markup) and 
> prints them nicely at the beginning of wikitext.

Error messages at the place where the erroneous markup was make it 
easier to assign the cause of an error.

>> Note that I strongly advise against popping up windows anyway. It's 
>> annoying to people who want to open the window in a tab (instead of in 
>> a new window), for example - the link to the photo would ignore the 
>> new tab and open a new window anyway. It will also exclude those users 
>> who have disabled Javascript for security reasons (as Yours Truly has).
> 
> Hmm, I'm also not a fan of JavaScript. On the other hand
> 
> - A standardized client-side script language is needed, and JavaScript 
> seems to be the only one more or less supported by major browsers

Agreed.

> - My own webserver statistics show that 99.8% of all visitors have 
> javascript enabled

This means that 99.8% of all visitors are potential spam sources :-(

> - The language itself is quite secure, only some implementations and 
> some extensions (e.g. IE's JScript) are not.

It's always the implementations that are unsecure.
And all those IE alternatives shouldn't rest on their laurels - Firefox 
just plugged some security holes, only weeks after the 1.0 release.

The problem is that JS is far too complicated to be safe. There are 
simply too many things that can go wrong, and a single error can make 
the entire implementation unsafe.

> - IMHO, disabling Javascript is just not the right solution. This is a 
> destructive approach, since lots of useful functionality is lost. The 
> same goes for restrictive firewall admins ;-)

Enabling JS isn't the right solution either. JS is the worst security 
hole within a computer (the worst overall security hole is sitting in 
front of the keyboard though...)

Regards,
Jo