From: Steve W. <sw...@wc...> - 2001-02-23 03:11:56
|
and now, part two: On Thu, 22 Feb 2001, Arno Hollosi wrote: > Otherwise all you needed doing would be testing for $phpwikidir/locale/.... > Next point: people like Pablo combine phpwiki with other applications. They > might make use of include_path as well. How big are the chances that there > is another lib/config.php, lib/main.php, ... To avoid collision we would > have to rename either the files to wiki_* or the directory to wiki_lib/* > Both look not attractive to me. Why mess with this stuff? include_path is > not as straight forward as $phpwikidir. What are the benefits? > I don't see any. As for cons, see above. We haven't considered making PhpWiki easy to integrate with other things so far, and I don't intend to start now. Anyways any coder who would undertake such a thing can just rename the files for now. > Ok, maybe I have to be more precise. I don't like your style of OO. > Don't take this as personal offense. I think you are a great programmer, Second that... > > The $pagehash can, I think, truly benefit from becoming a bona fide > > object. > > This is the one I strongly argue against. Currently $pagehash is a set of > variables which can be modified easily *throughout* the code. Once you turn > $pagehash into an object phpwiki becomes a completely different application. Hmm. Could you elaborate on this a little, Arno? > > 2. The SF task list has been growing at a seemingly exponential rate. > > Only because it's on the task list doesn't mean we have to implement it. > Steve uses it as kind of wishlist - not as a definite TODO list. Also many of the things on the task list are little things, like renaming the database tables. > > PS: Hey! What's wrong with emacs? What do you use/suggest? > > I don't know of any good php development platforms. It's even worse if you > have lots of classes and stuff. This is a well known deficiency of PHP. > That may be true for the db api, but not for general discussions. I don't > like having to check many places for information - a mailing list is easy, > everything is in one place and it's pushed at me (instead of pulling it > from webpages). I think there's a reason why 99.9% of all open source > projects have mailing lists as their primary communication medium. I created one page (NewDatabaseApiAndSchema) in the hopes that we could limit our discussion there, but I was naive and should have stated my wish to contain this thread on one Wiki page (since by not quoting parts of an email, context is lost). > And yes, I think it would be healthy to establish some development goals > and guidlines for phpwiki. Implementing new features is fun. But without > clear goals we end up writing a big, bloated app capable of doing just > about everything, but so complex that not anyone is really going to like it > (and so far away from WikiPhilospohy that noone will recognize it as a wiki > anymore). And maybe some coding guidelines should be discussed as well. Coding guidelines are on the task list. Again, if you look at the task list, it's all doable and really the end-all, be-all a Wiki can be. At heart it will still be a clone of the Portland Pattern Repository, but it will also serve as an elaborate hypertext system for whiteboarding ideas. > Compare pwiki and phpwiki - I think the reason why people choose phpwiki is > that it's so simple to install, customize, and extend. Once you take these > properties away phpwiki has lost it's appeal. Interestingly enough people > who are attracted to phpwiki because it's so simple are the first ones to > propose extensions to the functionality. Such is the nature of programmers... you being one of them, since I never intended to port Phpwiki to MySQL, but you changed my mind. Look where we are now! ;-) So: the discussion is about the features we want to implement. I think there are a few I added that are really just wishes (like page types, which would add a lot of complexity), some that are going to be rarely used (like hosting multiple Wikis off the same install base), and some that are really, really important (good version control and user authentication). State your piece. ~swain ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |