[pmwiki-users] Any hope for 2.2.0 stable release?

[ml]

Hello,

 > PHP4 support is holding us back, then we can consider it.

I think there is some nice stuff:
- auto class loader for inclusions in stdconfig.php
- try catch error handling, esp. usefull for markup extensions, cookbooks
- __destruct instead of register_shutdown_function
- major projects are moving to php5 (e.g. smarty, phpMyAdmin)

 > it might break a ton of sites and recipes, so we really need a

Yes, recipes might also have to move away from GLOBALS, but I think most 
will like it.

 > them portions of the code become very very long and unreadable (to me).

At least some PHPdoc can help when moving the mouse over it in Zend/PDT, 
e.g.:
/**
 * strip backslashes
 * @param string $x
 * return string
 */
function PSS($x) {
    return str_replace('\\"','"',$x);
}
Putting it in the class Markup might also be an option.

 > some way of either (1) converting all pages on a site to UTF8,
 > or (2) automatically probing for all filename types that

As most literature says it can't be done automatically, I'd recommend a 
migration script (see http://www.dokuwiki.org/tips:utf8update, 
http://www.phpwact.org/php/i18n/charsets).
I can also image having some different directories like wikilib.d and 
wikilib.d.utf8

 > Actually, now that I think about it, I might have a good way to
 > do #1, so perhaps we can work on this soon.

Great!

bye
Thomas


Patrick R. Michaud wrote:
> On Tue, Jan 20, 2009 at 12:10:56AM +0100, ml wrote:
>   
>> here are some proposals for the code:
>> - reduce $GLOBALS (e.g. $t in forms.php)
>>     
>
> I very much agree with this one.
>
>
>   
>> - drop PHP4 support (outdated)
>>     
>
> I don't see dropping PHP4 support as a goal on its own.  If
> there is something that we want to add to PmWiki and where
> PHP4 support is holding us back, then we can consider it.
> But there are still a lot of sites (including pmwiki.org)
> that are using PHP4 and I don't see any purpose in dropping
> PHP4 support for its own sake.
>
>
>   
>> - move confiiguration items to a separate class ($GroupPattern, $NamePattern,
>> etc. => class members), no more "global $StopWatch"
>>     
>
> I don't know that we'll eliminate global variables entirely.
> If I had things to do over again, I would put all configuration
> variables into a $Config array and provide some functions to
> easily set defaults and obtain values from that array.  This
> would also make a "control-panel" type interface easier.
>
> The problem with simply switching to such a structure now is that
> it might break a ton of sites and recipes, so we really need a
> smooth migration plan.  Hopefully one that doesn't involve a long
> "beta" series.
>
>   
>> - reduce unusual abbreviations (PSS, PVS, PVSE, PZZ, etc.) 
>> and/or add PHPdocs to help Zend/PDT users reading the code
>>     
>
> The unusual abbreviations are there for a reason -- without
> them portions of the code become very very long and unreadable (to me).
> I have no problem with documenting these functions very well, but
> I prefer to keep the abbreviations.
>
> Stated differently:  Most communication forums and (written) 
> languages have abbreviations in them for a reason -- they 
> serve to simplify communication among people working within
> those arenas.  Yes, it sometimes means that newcomers to the
> system have to become familiar with the abbreviations, but
> that doesn't mean that we should throw them out entirely.
>
>   
>> - make UTF8 the default encoding
>>     
>
> This is the one I'd be most eager to see us tackle, but also 
> one of the most difficult.  It's not a problem for new
> installations of PmWiki, but it's very difficult to provide
> a way for existing sites to convert over to UTF8.
>
> I've already put some internal items in place to help with
> this -- for example, each page file includes a field that
> indicates the page encoding used to save the page.  We could
> use this to convert page text on the fly.
>
> More difficult is dealing with page filenames -- we would want
> some way of either (1) converting all pages on a site to UTF8,
> or (2) automatically probing for all filename types that
> could exist.
>
> Actually, now that I think about it, I might have a good way to
> do #1, so perhaps we can work on this soon.
>
> Pm
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20090121/7c5bcd1e/attachment.html