<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
here are some proposals for the code:<br>
- reduce $GLOBALS (e.g. $t in forms.php)<br>
- drop PHP4 support (outdated)<br>
- move confiiguration items to a separate class ($GroupPattern,
$NamePattern, etc. => class members), no more "global $StopWatch"<br>
- reduce unusual abbreviations (PSS, PVS, PVSE, PZZ, etc.) and/or add
PHPdocs to help Zend/PDT users reading the code<br>
- make UTF8 the default encoding<br>
<br>
bye<br>
Thomas<br>
<br>
<br>
The Editor wrote:
<blockquote
cite="mid:fec7cf150901191346g7d945b20xcc6e86d289468742@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Jan 14, 2009 at 6:37 PM, Petko Yotov <a class="moz-txt-link-rfc2396E" href="mailto:5ko@5ko.fr"><5ko@5ko.fr></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">* 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> .
</pre>
</blockquote>
<pre wrap=""><!---->
Just a note or two of agreement here. There are many ways to organize
code--and in my limited experience, the simplest is usually the best
approach. Switching things unnecessarily to OOP will not only leave
out PHP4 servers (yes, some still use it), but will make the code less
accessible to more ameteur programmers. I have developed several
plugins using already developed OOP scripts and found them 10x more
difficult to integrate. Granted, I'm one of those "ameteur"
programmers--but that's exactly the point. PmWiki was so beautiful
because when still a novice I could quickly access and grasp what was
happening. And then hack to my heart's content.
Pm's (and PmWiki's) genius is not just in the code, but in his gift of
teaching and his/its ability to engage learners. Please don't lose
this characteristic of PmWiki. I personally have been tremendously
blessed by it.
</pre>
<blockquote type="cite">
<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="">* 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.
</pre>
</blockquote>
<pre wrap=""><!---->
In my other post I mentioned BoltWire's use of a simple site.config
page, where most settings can be modified in a special wiki page as
desired. The php handling this feature gives dominance to config
settings in a php script (which can do more dynamic configuration),
but for most cases, simple system wide settings work fine. It's also
fully extensible, so any plugin can call a function which looks for a
specified config variable, and returns a default if not found. Meaning
the same page can be used for any and all plugin settings/options. The
php code is trivial--but it opens up easy in-wiki configuration.
I don't know if something like this is possible currently in PmWiki,
but Petko's plugin sounds promising. At most, it would take a few
lines to generate a simple hook which could easily be set to off by
default, if desired. It would require a scouring of the code to
identify every variable you might want to potentially allow support of
in-wiki configuring, but that can be done incrementally as the need or
interest arises.
</pre>
<blockquote type="cite">
<pre wrap="">* 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>
<pre wrap=""><!---->
Thanks for mentioning BoltWire :) However I might disagree slightly
with your conclusion. BoltWire was created because of limitations ZAP
kept bumping up against within PmWiki, and even more as an experiment
to test the limits of making form processing more central to a wiki's
internal architecture. And for me personally, the results of that
experiment were surprizingly positive--in terms of increased
flexibility, smaller code base, and performance. Regardless of the
pro's/con's (Pm made many reasonable arguments for not pursuing this
path in the core), I tend to think Henrik may have something here.
Granted, PmForms can do basic data storage and retrieval. And Fox has
even more extensive capabilities. But a little open discussion in this
area might lead to minor changes in the core that could dramatically
reduce development time for web projects. Talking with developers at
other wiki's on occasion, I sense more of them are moving in this
direction. PmWiki is definitely out towards the front, but others are
closing in. I would recommend more aggressive work in this area.
By way of side note, after getting so excited about this "new concept"
so central to the spark behind BoltWire, I was surprized to recently
read these wikipedia articles. Worth taking a look at. At the very
least someone should add PmWiki to the list...
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Wiki_application">http://en.wikipedia.org/wiki/Wiki_application</a>
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Structured_wiki">http://en.wikipedia.org/wiki/Structured_wiki</a>
</pre>
<blockquote type="cite">
<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.
</pre>
</blockquote>
<pre wrap=""><!---->
I about choked on Henrik's statement here. Pm is one of the most
kindhearted and generous individuals I have ever encountered, and the
support community here is dynamic and helpful. This very thread is
certainly proof of that. If development has slowed, my guess the cause
is not so much issues revolving around Pm, near as much as around the
fact the code works so flawlessly to the satisfaction of so many
individuals. Bug reports, security vulnerabilities, feature requests
unsupported by some plugin, etc., are so rare the mailing list has
gotten to be a bit boring reading lately! :) That's not
laggardliness, it's just plain old good software.
There may be areas for improvement. (I threw my friendly 2 cents
in--and could suggest more). But to use a loaded word like "laggard"
struck me as a bit out of line. It's easy to fire stuff of by email
without thinking. Let's hope that's all this comment was.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
There are scripts that can check a file for proper UTF-8 encoding, and
other utility scripts that can be used to convert entire wiki's from
one encoding to another. In researching this topic, I found it a
rather complex and challenging problem--but implementing the
transition ended up going quite smoothly. I'm sure it's simply a
matter of someone setting their mind to it and doing it. And for that
matter there's no one stopping someone from offering some conversion
utility as a plugin. Just a thought.
Best wishes to Petko in his new role. And congrats to Pm on finding a
good partner. Regards to the whole community.
Cheers,
Dan
_______________________________________________
pmwiki-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pmwiki-users@pmichaud.com">pmwiki-users@pmichaud.com</a>
<a class="moz-txt-link-freetext" href="http://www.pmichaud.com/mailman/listinfo/pmwiki-users">http://www.pmichaud.com/mailman/listinfo/pmwiki-users</a>
</pre>
</blockquote>
<br>
</body>
</html>