From: Jeff D. <da...@da...> - 2001-02-21 22:47:55
|
Welcome back, Arno! >- the new layout looks nice, but packing the whole page into a table just >to make it look nice is not really browser friendly. Point taken. - the rush for new wiki markup (tables, picture floats, ...) -- I don't like that at all. I'll stay out of this one, except to say: I wanted simple tables, so I added them. (And you're the one who added footnotes! :-) ) >- ...I don't like messing with the include path. Instead I suggest > ... including all other files with "$phpwikidir/lib/filename.php". >Much easier to understand, less things to mess around. ... Hmm. I respectfully disagree. ini_set("include_path", "/some/where") seems pretty clear to me. >- the phpwiki code gets more and more complicated. That's against one of >our primary design goals (at least we had this goal some months ago). More later. But, just in the way of explanation: > * prepend.php -- why do we need this fancy error postponing? I put that in because error/warning messages were making for corrupt zip-dumps. I suppose I hide it in libzip.php. > * config.php -- why do we need FindFile(), FindLocalizedFile() etc. > we didn't need these functions before. What makes them necessary now? The idea was to make clear distinctions between PHP code (located via include_path), language-independent data files (FindFile), and localizable data fiels (FindLocalizedFile). I'll admit that FindFile and FindLocalizedFile should bear comments to that effect. >There are other places as well. Keep the code simple. Fancy stuff should be >removed and the code kept clear and easy. > >- about the templates: some are proposing to make them more sophisticated. >I argue against this. The end result is (after adding loops etc.) >reinventing PHP or other HTML-embedded languages. True, but we are inventing a (hopefully) simple HTML-embedded language. I would argue that if one is to have templates at all, they should be there to provide a clear separation between the design and programming of the page. As it stands some things (like ###RELATEDPAGES###) have their layout set in PHP code, while others are layed out in the template files. Adding a new "theme" to a current PhpWiki more than likely requires editing some PHP code. What do the current templates provide now that couldn't be just as easily provided by straight PHP files consisting of mostly HTML interspersed with things like "<?php echo $RELATEDPAGES; ?>"? At least this would provide the opportunity to intersperse larger chunks of PHP code to generate tables and such. (Answer in part to this question: one can not (I think) capture the output of an include("template.php") --- it always gets spewed straight to the client.) >We had some discussion about this some months ago - dig it up in >the list archive. I tried, but haven't found anything particularly deep yet. Geocrawler keeps periodically crashing my Netscape, which makes it difficult. >- object orientation: I know Jeff likes OO, I don't. I guess that "easier/harder to understand" is very much a matter of personal opinion. I view the database backend as a thing. A thing upon which one can perform certain actions, some of which produce other things (of a different sort). It really just _screams_ "please implement me as an object". Maybe, in this case "object" is not the right word. Perhaps "concrete class" and "class oriented" would be better terms. The current code is already written pretty much in this manner. The $dbi is a thing with a well defined set of methods which can be applied to it (DBLIB.txt). Why not use the tools provided by the language to make this explicit. The $pagehash can, I think, truly benefit from becoming a bona fide object. There are many properties of a page which must be determined in a backend-dependent manner. In some backends certain properties (e.g. backlinks) may be expensive to determine. Different types of pagehash objects could be generated by the different backends. They would all inherit basic and default methods from an underlying base class. >In short: keep it simply. phpwiki is getting too fancy for my taste. This is a point on which a policy decision should definitely be made. (Or restated, if it's already been made.) Some things to think about: 1. "Simple is in the eye of the beholder." (See above.) 2. The SF task list has been growing at a seemingly exponential rate. (For the most part, not my doing.) All kinds of fancy features have been discussed: page types, user authentication, version history. If or when all these features are added, phpwiki is not going to be a small program. No matter what your definition of "simplicity" is, maintaining it with all these features thrown in is not going to be easy. Jeff PS: Hey! What's wrong with emacs? What do you use/suggest? PPS: The wiki (http://phpwiki.sourceforge.net/phpwiki.) might be a better place in which to carry out much of this discussion. |