Re: [Phpwiki-talk] back again

[Jeff D. <da...@da...>]

>It is excellent work... and you're not alone when you say OOP designs are
>harder to understand. They are. 

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.
However, some of the other things which are expressed as classes in
my code could be just as clearly expressed without classes. 
(My motivation in these cases stems mostly from my deep --- at times,
irrational --- loathing of global namespace pollution.)

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

>When I think about PhpWiki's "usability" I think of it in three terms: 
>* And, how easy is it to understand the program design and modify it?
>(hacker usability)

I'll be the first to admit that my new code could use some documentation.
I'll work on it.  Also, I'm still uncomfortable with my new
wiki_transform/wiki_renderlib code.  I'm happy with it's functionality,
but the code is admittedly less than transparent...


Some coding standards would be good.

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.

>We will not abandon 1.1.7 (to be 1.2). I want to finish it up and the list
>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.

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

  3. Dump/load serialized (or MIME encoded) pages.  Do we need this too?
     My vote is no.

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

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

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.

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

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

  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.


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

Jeff