<!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">
Petko,<br>
<br>
I've been running PmWiki on a PHP5 server as well. Although there were
a couple of minor glitches, Patrick addressed them, and everything
works well now.<br>
<br>
But I believe the next step is to stop supporting PHP4, by which I
mean, transition more to the OOP features of the language, eventually
exclusively.<br>
<br>
I don't buy the contrarian view of OOP that you offer. The benefits of <a
href="http://en.wikipedia.org/wiki/Object-oriented_programming">encapsulation,
modularity, polymorphism, and inheritanc</a>e are well established, and
virtually universally accepted. These include:<br>
<br>
- Closer match between design objects and implementation objects,
making development more successful.<br>
- improved modularity, and looser coupling among modules, making
development, including team development easier (very relevant to this
discussion of considering moving to a community development model)<br>
- more concise and re-usable code. In the case of PmWiki the code may
be concise, but it certainly isn't easily re-useable (see below).<br>
- availability of a wide variety of useful design patterns that apply
to the OOP paradigm.<br>
<br>
Furthermore, the developers of PHP are apparently committed to focusing
on developing the OOP side of the language, adding improvements there
that will eventually surpass the efficacy of the legacy part of the
language, viz the new class <a
href="http://www.devshed.com/c/a/PHP/Auto-Loading-Classes-in-PHP-5/">autoloader</a>
for example. It would be prudent to position PmWiki to take advantage
of this effort.<br>
<br>
Finally, PHP 5 (and 6) are being positioned to address some of the
long-standing language problems, notably the arbitrary organization of
language functions (generally considered to be a mess), and the lack of
namespaces. These are being addressed in PHP 5 and 6, from what I can
see with an emphasis on the OOP side of the language.<br>
<br>
You ask if there is a problem that you cannot see that requires
migration to OOP. Have you tried to follow the PmWiki code? With the
greatest respect for Patrick, it falls into all the traps available to
structured programming, notably over-use of globals, and unending
reliance on hidden side effects. You can argue that some of this was
done for conciseness and performance, but it has the drawback of being
difficult to maintain. In the current context, it has the drawback of
being virtually impossible to maintain by a group.<br>
<br>
Another benefit of a re-write, not to be dismissed, is that it is an
opportunity to disentangle some of the concepts that have developed
incrementally over the years. In other words to clarify the design of
the product, and reflect this clarity in the new code.<br>
<br>
Regarding features of the product:<br>
<br>
The list I offer comes from many years experience in offering PmWiki
based websites to a number of community organizations in Toronto (about
30 sites, of which a handful are pretty active). <br>
<br>
For an example of file Management, see for example DocuWiki's <a
href="http://www.dokuwiki.org/mediamanager">mediamanager.</a><br>
<br>
I think the benefits of an administrative interface are obvious: it
lowers the skill level required to manage the supported features,
making the product more accessible, and greatly broadening its reach.
This would be true even if the supported features were selective, not
univeral.<br>
<br>
I have seen and investigated the form based entry systems that exist.
These are terrific efforts, but are (IMO) still early, and awkward.
Based in my experience of supporting many PmWiki installations, one
thing that I have found consistently is that for sophisticated use of
wiki markup, the complexity of embedded instructions is a persistent
and important barrier to authors. Support for customizable,
configurable form based entry would IMO radically expand the potential
user base of PmWiki, and owing to the very work that you reference,
this feature is relatively accessible, but requires further development
effort. Furthermore, it would greatly alleviate the pressure for a
WYSWIG entry interface.<br>
<br>
I would add decent "feed" capability, including useful RSS
support. <br>
<br>
I'm sure others have need of features that they see in
other products.<br>
<br>
PmWiki is most certainly a laggard by now. The current version has been
in beta for far too long (for well justified personal reasons as we
know), while the rest of the world is not standing still. See for
example <a href="http://habariproject.org/en/habari-and-php5">habari</a><br>
<br>
In any case, surely as a product matures, if it is to become
established in the long term, it requires an active community of
developers to sustain it (for the core!). <br>
<br>
My contention is: it is time for this to happen.<br>
<br>
To be clear, I do not mean in any way to diminish the accomplishment of
PmWiki. Instead I am arguing in favour of a clear way forward, to
consolidate the gains made, and establish a foundation for capturing
even higher ground.<br>
<br>
Nor, of course, is any of this to suggest in any way the replacement or
pre-empting of Patrick. That would be awful, as he's the genius behind
this product. Instead, my initiative is aimed at finding a practical
way of organizing support for him and his efforts. I would hope and
expect that he would continue to be the designated "guru", the final
say, but in more of an "executive" role.<br>
<br>
Best regards,<br>
<br>
- Henrik<br>
<br>
Petko Yotov wrote:
<blockquote cite="mid:200901150037.55836.5ko@5ko.fr" type="cite">
<pre wrap="">On Wednesday 14 January 2009 20:02:46 Henrik Bechmann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">FWIW, if there was to be the formation of development team, I think it
would be worth considering going (more or less directly) to version 3,
being a migration to PHP5 and OOP.
</pre>
</blockquote>
<pre wrap=""><!---->
* I have my PmWikis running on PHP5 since 2005. The current stable and beta
work extremely fine with PHP5.
* OOP is not a goal in itself, but a means to some goal, and it is only worth
the effort in some cases. See "OOP Myths Debunked" at
<a class="moz-txt-link-freetext" href="http://www.geocities.com/tablizer/oopbad.htm">http://www.geocities.com/tablizer/oopbad.htm</a> .
PmWiki uses an OOP PageStore class that allows excellent integration of
different storage mechanisms such as a database instead of or in addition to
the filesystem, or a different filesystem configuration. Almost every other
aspect of PmWiki can be configured via enabling a variable and providing a
replacement function, without modifying core files. Every core script, should
it be changed, may be placed in the /cookbook/ directory and be included
instead of the original one.
Is there a problem I cannot see, that requires migration to OOP?
</pre>
<blockquote type="cite">
<pre wrap="">My three main feature requests: resource file management, an
administrative interface, and a form-based content entry option.
</pre>
</blockquote>
<pre wrap=""><!---->
* What is resource file management?
- Deleting attachments is possible wia recipes : Cookbook:Attachtable
and others
- Uploading CSS files or whole skins via PmWiki's ?action=upload can be
made possible by adding two lines of code to farmconfig.php.
* A recipe could be written to add an administrative interface. It may already
exist. I have used myself for months a small snippet and I'll soon release it
on the cookbook. It allows some selected config variables to be overridden by
editing special wiki pages. Not form-based but does the job.
* There are more than one recipes for form-based content entry. One is PmForm
by Pm, other is Fox by HansB, a third, new one, is Blogger by DaveG.
There is also another wiki project inspired by PmWiki and ZAP, which I believe
has more form-based administration options. See <a class="moz-txt-link-freetext" href="http://www.boltwire.com/">http://www.boltwire.com/</a> .
Personally, I believe adding more features like these should be in recipes and
not in the core. For the core, we should follow the PmWiki Philosophy.
</pre>
<blockquote type="cite">
<pre wrap="">I think that the combination of targets such as these could take PmWiki
back from being a laggard, to leapfrogging to the head of the line.
</pre>
</blockquote>
<pre wrap=""><!---->
PmWiki is not laggard. I have not seen any other wiki that allows even half of
the features PmWiki could plug-in, without the need to modify core files and
potential problems on upgrades. Some core features like PageLists and
PageTextVariables are quite unique in the wiki-world. The built-in search
engine is better than any other wiki, with the best ratio performance vs
CPU+fsystem usage.
The only thing I believe would be better, is to enable UTF-8 support in the
default installation, but currently it is difficult for the script to know
whether the wiki uses or not a custom character encoding, so an existing wiki
that upgrades could occasionally break. We'll figure something out.
Thanks,
Petko
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Henrik Bechmann
bechmann.ca
</pre>
</body>
</html>