Re: [Phpwiki-talk] back again

[Steve W. <sw...@wc...>]

On Thu, 3 Aug 2000, Jeff Dairiki wrote:

> Sorry.  When I write new code it tends to come out that way.
> I think that some things, like the pagehashes and dbis really are 
> (already were) objects, and are best expressed explicitly that way.

Oh yes, we've gone over that previously. We're totally behind you on the
$pagehash and $dbi issues; they are objects and will benefit from OOD.

You also made it plain you were hacking experimentally, so I never
expected readable/production ready code either. No apologies needed,
because no offense was given.

> (My motivation in these cases stems mostly from my deep --- at times,
> irrational --- loathing of global namespace pollution.)

Yeah, PHP has the same weakness with globals as Perl and Tcl. They are
bothersome.

> As always, feel free to make criticisms --- and to make or suggest changes 
> --- I'm pretty thick skinned.

We'll use blunt instruments ;-)

> BTW, do you all use any auto-indentation tools?  I've been using php-mode
> in emacs, and can't get it to duplicate your style.

I use the space bar :-) But I'll check out the php-mode for Emacs since
I've been using it lately (Emacs that is).

> >of things to do is not very long. Jeff, would it be hard to hack the
> >admin design you came up with into the 1.1.7 tree?
> 
> No problem.  Tell me though: how much of the admin functionality that's
> currently in 1.1.7 do we really want?
> 
>   1. Admin browse mode: lock/unlock pages and edit locked pages.

yes...
 
>   2. Zip export.  Do you like the current zip file (MIME) format?

yep...

>   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.


>   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).

low demand; we can wait for someone to contribute it :-) But I do think
people will want static HTML snapshots someday. 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).

>   5. Convert 1.0 DBMs.  Currently the code in wiki_setupwiki can load pages
>      from either a directory ("pgsrc/") or a zip file.  The source used is
>      specified by the setting of WIKI_PGSRC in wiki_config.
> 
>      My inclination is to allow WIKI_PGSRC to be set to a version 1.0 DBM as 
> well.
> 
>      I guess the question is whether there should, in addition, be some
>      method other than WIKI_PGSRC to load pages from zips/dirs/1.0DBMs.
>      I guess so.

Yeah, I can continue responsibility for 1.0 loading; backwards
compatibility is a millstone around one's neck though. (It's such a
trouble, that is).

>      Should there be a web-admin option to blow away the current database
>      contents completely?  Or should the new pages always just load over
>      the old ones, leaving the old contents in the archive?

Ouch.. never erase, would be me philosophy. We can't do the admin's job
for them, just make it easier. Loading pages should follow the same
procedure as any Wiki page insert/update. (InsertPage())

> Other issues for 1.2 (other than whats already in the TODO.)
> 
>   Move the lib files to a wiki/ subdirectory (and drop the wiki_ prefix?)
>   I think this is a win/win proposition, and we should just do it.

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.
 
>   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.


>   (Related to admin issue 2, above:) are we going to keep page refs in 1.2?
>   Leave them in the database but hide them from the user?  Drop them 
> completely?
>   (My vote is leave them in the database, but hide them from the user:
>   convert them to inline links both when the page is edited, and when
>   the page is exported to a zip file.  This would ease the total abandonment
>   of page refs in 1.3 and beyond.)

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? Not us. We are
evolving away from Ward Cunningham's classic WikiWikiWeb.

>   I.e. I'd rather not make page refs part of the "PhpWikiZip standard" if
>   they're going to be dropped in the next version of PhpWiki.

They are going to be dropped, and you have your papal dispensation :-)

> I'm going to be on a road trip from tomorrow morning through Monday, so don't
> worry if I'm strangely silent.

Have fun! Wear your seat belt! :-)

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain