From: Jeff D. <da...@da...> - 2000-08-03 20:22:41
|
>Yeah, PHP has the same weakness with globals as Perl and Tcl. They are >bothersome. At least Perl's got modules. Don't know about Tcl. >> 3. Dump/load serialized (or MIME encoded) pages. Do we need this too? >> My vote is no. > >Hmm. Iffy. Overall, I'd rather not focus too much effort on the admin >tools. Good, I'll ignore that. >> 4. Dump HTML pages. Do we need this? I think this is a low demand item, >> and that it's better done with some external tool (script). > >Imagine a group of >programmers, if you can, who are documenting a system. They won't want to >ship a Wiki to the customer (sadly). Okay, I understand the point now. I think it should wait until after 1.2. >OK... I'd keep the prefixes though. I think there's something about the >way PHP does searches along the include path that any duplicate file names >clobber each other even if they are in different directories. I was actually thinking of not relying on a search path. Just replace "include('wiki_stdlib.php3')" by "include('wiki/stdlib.php3')". (Or perhaps "require('wiki/stdlib.php3')" -- any reason not to?) (Or maybe "require('wiki/stdlib.inc')" which seems to be a more standard naming convention --- not that it matters.) The include path stuff, while slick, is, I think, a portability headache. AFAIK, the path has to be set either in system config files (bad); or in .htaccess files, which can only be done under Apache, and then only if things are configured correctly. >> PATH_INFO? I personally don't really care if this goes into 1.2 or not >> (as long as it makes it in at some point.) > >PATH_INFO is a Good Thing because: it will make URLs a little easier to >read, indexing by search engines a little more likely, and ... well that's >about it. Easier for users to remember/type. Okay I'll probably hack that in then. Hacking in the admin browsing is going to requires messing around with the URLs anyway. >> (Related to admin issue 2, above:) are we going to keep page refs in 1.2? > >Can't we just leave them where they are, and ignore them when exported? >This sounds like a case of Worse Is Better. Refs work now, require no more >thought on our part, and if they are lost when exporting to file, fine. >Not perfect but who wants to put the effort into it? It loses page content, seems bad. At the very least I'd want to add the references as "footnotes" to the bottom of the page content, so they're still there, and can be fixed manually if desired. I'll work on this stuff next week. Jeff |