<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
> PHP4 support is holding us back, then we can consider it.<br>
<br>
I think there is some nice stuff:<br>
- auto class loader for inclusions in stdconfig.php<br>
- try catch error handling, esp. usefull for markup extensions,
cookbooks<br>
- __destruct instead of register_shutdown_function<br>
- major projects are moving to php5 (e.g. smarty, phpMyAdmin)<br>
<br>
> it might break a ton of sites and recipes, so we really need a<br>
<br>
Yes, recipes might also have to move away from GLOBALS, but I think
most will like it.<br>
<br>
> them portions of the code become very very long and unreadable (to
me).<br>
<br>
At least some PHPdoc can help when moving the mouse over it in
Zend/PDT, e.g.:<br>
/**<br>
* strip backslashes<br>
* @param string $x<br>
* return string<br>
*/<br>
function PSS($x) {<br>
return str_replace('\\"','"',$x);<br>
}<br>
Putting it in the class Markup might also be an option.<br>
<br>
> some way of either (1) converting all pages on a site to UTF8,<br>
> or (2) automatically probing for all filename types that<br>
<br>
As most literature says it can't be done automatically, I'd recommend a
migration script (see <a class="moz-txt-link-freetext" href="http://www.dokuwiki.org/tips:utf8update">http://www.dokuwiki.org/tips:utf8update</a>,
<a class="moz-txt-link-freetext" href="http://www.phpwact.org/php/i18n/charsets">http://www.phpwact.org/php/i18n/charsets</a>).<br>
I can also image having some different directories like wikilib.d and
wikilib.d.utf8<br>
<br>
> Actually, now that I think about it, I might have a good way to<br>
> do #1, so perhaps we can work on this soon.<br>
<br>
Great!<br>
<br>
bye<br>
Thomas<br>
<br>
<br>
Patrick R. Michaud wrote:
<blockquote cite="mid:20090120140640.GB7266@pmichaud.com" type="cite">
<pre wrap="">On Tue, Jan 20, 2009 at 12:10:56AM +0100, ml wrote:
</pre>
<blockquote type="cite">
<pre wrap="">here are some proposals for the code:
- reduce $GLOBALS (e.g. $t in forms.php)
</pre>
</blockquote>
<pre wrap=""><!---->
I very much agree with this one.
</pre>
<blockquote type="cite">
<pre wrap="">- drop PHP4 support (outdated)
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">- move confiiguration items to a separate class ($GroupPattern, $NamePattern,
etc. => class members), no more "global $StopWatch"
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">- reduce unusual abbreviations (PSS, PVS, PVSE, PZZ, etc.)
and/or add PHPdocs to help Zend/PDT users reading the code
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">- make UTF8 the default encoding
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
<br>
</body>
</html>