phpwiki-talk

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

Re: [Phpwiki-talk] back again

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

>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

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