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

ml ml at simple-groupware.de
Mon Jan 19 17:10:56 CST 2009


here are some proposals for the code:
- reduce $GLOBALS (e.g. $t in forms.php)
- drop PHP4 support (outdated)
- move confiiguration items to a separate class ($GroupPattern, 
$NamePattern, etc. => class members), no more "global $StopWatch"
- reduce unusual abbreviations (PSS, PVS, PVSE, PZZ, etc.) and/or add 
PHPdocs to help Zend/PDT users reading the code
- make UTF8 the default encoding


The Editor wrote:
> On Wed, Jan 14, 2009 at 6:37 PM, Petko Yotov <5ko at 5ko.fr> wrote:
>> * 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
>> http://www.geocities.com/tablizer/oopbad.htm .
> 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.
>>> My three main feature requests: resource file management, an
>>> administrative interface, and a form-based content entry option.
>> * 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.
> 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.
>> * 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 http://www.boltwire.com/ .
>> 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.
> 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...
> http://en.wikipedia.org/wiki/Wiki_application
> http://en.wikipedia.org/wiki/Structured_wiki
>>> 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.
>> 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.
> 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.
>> 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.
> 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
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20090120/65e8aab4/attachment.html 

More information about the pmwiki-users mailing list