phpwiki-talk

[Phpwiki-talk] catching up ...

[Arno H. <aho...@in...>]

Hi there,

I'm back and try to catch up with you guys.

> It might be interesting to do a user survey to find out just
> what environments phpwiki is being run in.
> What do you and Arno deal with?

I'm using a vanilla installation from Suse Linux: Apache+php3+mysql
mySQL is updated to the latest stable version which is 3.22.32


> o Page meta-data (author, version, etc...) is saved in a special custom
>   header field in the zip file.   This information is not accessible via
>   any standard zip tools, but I plan on writing an unzipper which can
>   use this information to restore a Wiki from the zip file.  (The zip file
>   is (should be) still readable using any unzipper.)

Hm, I don't think using special fields within the ZIP is a good idea.
That way, if someone should touch the ZIP for whatever reason, that
data will be lost. I suggest using an extra file, or a meta-file for every
page-file.


> I want to add more DBM files to add the new functionality we've been
> adding, and I will change the way the DBM files are opened... I want to
> set it up so that we only need one call to OpenDataBase(), and we can do

Good idea.

> I added two new markup rules tonight. I want to do away with the use of
> tabs in the markup language since tabs are too difficult to use in Windows
> browsers. Right now we have:
> * one level, ** two levels, *** three levels
> # one, # two, ## one, ## two

I would like to be able to mix those two, e.g.

# one
#* some here
#* more there
#** even more here
#** even more there
#* some there
#*# some there . one
#*# some there . two
# two

Should be quite easy to do, no?
Use a regexp like "^([#*]*)([#*])" - the last char determines the
list type. The size of \1 plus \2 determines the level. If level or
type changes then close current list and issue apropriate HTML tags.

> 2. The line
>     [[Link] produces [Link].
>   gets munged.

Oddly enough I already had fixed this one a while ago.
Apparanetly some changes outside wiki_transform invalidated my fix.


> 3. '''''Bold italic''' and italic''

This is tricky. I suggest to use the new markup instead:
     ''__Bold italic__ and italic''

About /lib vs. /admin:
I think /lib is cleaner and reduces the clutter in the main
directory. But it's not an urgent issue.



When will 1.1.7 be shipped?
Where is Ari's code?

/Arno

[Phpwiki-talk] 1.1.7 and re: Catching up

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

Welcome back! :-)

On Fri, 14 Jul 2000, Arno Hollosi wrote:

> > o Page meta-data (author, version, etc...) is saved in a special custom
> >   header field in the zip file.   This information is not accessible via

> Hm, I don't think using special fields within the ZIP is a good idea.
> That way, if someone should touch the ZIP for whatever reason, that
> data will be lost. I suggest using an extra file, or a meta-file for every
> page-file.

I didn't catch this before, but now I do, and I agree with Arno.. the less
we rely on proprietary solutions the better. I'd rather hack a loader to
read two files per page that suffer Jeff with mucking with Zip files too
much. It hides the information from the user as well (a separate metadata
file can be edited in a text editor, can be cat'd, grep'd and so on).
Putting it in the Zip file means it's almost human-inaccessible.

> I would like to be able to mix those two, e.g.
> 
> # one
> #* some here
> #* more there
> 
> Should be quite easy to do, no?

Yes, but I'm confused. Is there a reason to allow arbitrary mixing?
 
> About /lib vs. /admin:
> I think /lib is cleaner and reduces the clutter in the main
> directory. But it's not an urgent issue.

Hmm. I guess I'm in the minority on this one!

> When will 1.1.7 be shipped?
> Where is Ari's code?

Always one step ahead of me! 

I was waiting for you to return before calling for 1.1.7. Right now it's
stable and I see no reason not to release 1.1.7 right away -- this will be
the Jeff release! It includes all his cool diff stuff, the zip stuff, your
additions to the admin/ files, and the few things I added.

That said, if you want something in 1.1.7 that isn't there now speak up;
otherwise I will release 1.1.7 over the weekend.

I invited Ari to join us but never heard back. If there's something
specific you want to see in the nbtsc.org Wiki's source I have access to
it. Ari wanted to clean up the code and publicly release it, but I'll ask
if I can make a tarball of it as-is since we are all professionals and we
all do strange things in the privacy of our own servers, and Ari has
nothing to be ashamed of :-)


Things we've discussed, but have not reached consensus on (or maybe we
did, phpwiki-talk has been extremely active) include:

* moving to PATH_INFO. Ari has code we can use. This involves more than
you think because we get things like $copy, $edit, $info for free now from
PHP and using PATH_INFO means we'll have to roll them by hand;

* moving files to lib/ which has the benefit of allowing better security
like Jeff set up;

* refactoring the database interface, which will start with the DBM
changes and then involve a lot of search/replace of variable names
(renaming all instances of $ArchiveDataBase to $ArchiveTable, or something
better, for example);

* possibly moving to an OO approach to the database interface after that;

* I'm sure I missed something;

and there are a number of features we discussed a couple of months ago
that I would have to search the mail for, like all the pages we added
tables to the database for etc.

However these things can go in 1.1.8 or later; I think we are on track to
release 1.2 in a couple of months (depending on how much time we all have)
and there will probably be two or three releases between now and then.

sw

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

Re: [Phpwiki-talk] 1.1.7 and re: Catching up

[Arno H. <aho...@in...>]

 > That said, if you want something in 1.1.7 that isn't there now speak up;
 > otherwise I will release 1.1.7 over the weekend.

No special wishes this time :o)
Maybe Jeff should clear up the ZIP issue first.
As soon as 1.1.7 is out we can start TheBigRefactoringOfPhpWiki.

Because of 1.1.6 I had a look into testing suites for web-applications.
So far I haven't found anything proper. I found tools that check
for links and stuff. But what we'd need is a tool that requests
specific URL's, does POSTs as well, and then checks not only that
a page is returned, but verifies the returned HTML as well (simple
diff or by using regexp rules) Does anyone know of a beast like that?
A more rigorous testing of phpwiki would benefit us all :o)
Maybe I just write a small perl script using wget and netcat.


 > > [...lists...]
 > Yes, but I'm confused. Is there a reason to allow arbitrary mixing?

E.g. you have a list of "10 steps to do this&that"
So you have a numbered list for those steps (level 1).
Point 1 checks if everything is here "* tool x, * tool y, * tool z"
The tools don't have any order - so I'd like to use simple bulleted lists.
Voila - bulleted list inside numbered list.


 > > About /lib vs. /admin:
 > > I think /lib is cleaner and reduces the clutter in the main
 > Hmm. I guess I'm in the minority on this one!

As I said: it isn't urgent. We have more important things to do.
In the long run /lib seems more appropriate.


 > * moving to PATH_INFO. Ari has code we can use. This involves more than
 > you think because we get things like $copy, $edit, $info for free now from
 > PHP and using PATH_INFO means we'll have to roll them by hand;

Shouldn't be too hard.

 > * refactoring the database interface, which will start with the DBM
 > changes and then involve a lot of search/replace of variable names
 > (renaming all instances of $ArchiveDataBase to $ArchiveTable, or something
 > better, for example);

I think this should go into 1.1.8
I'm not sure I'm for a 100% oop approach - I'll give this some more thought.

/Arno

Re: [Phpwiki-talk] 1.1.7 and re: Catching up

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

On Sat, 15 Jul 2000, Arno Hollosi wrote:

> 
>  > That said, if you want something in 1.1.7 that isn't there now speak up;
> Maybe Jeff should clear up the ZIP issue first.
> As soon as 1.1.7 is out we can start TheBigRefactoringOfPhpWiki.

I've tried it and it works... you get a dump of all existing pages, sans
metadata, plus the other dumping features work reasonbly well (for beta
release), but I'll wait until tomorrow to see if Jeff wants to add
something more. (Or soonder if you reply now, Jeff! :-)

> A more rigorous testing of phpwiki would benefit us all :o)
> Maybe I just write a small perl script using wget and netcat.

Yeah, testing is always an issue. I don't know of anything that does what
we need, haven't looked though.
 
> E.g. you have a list of "10 steps to do this&that"
> So you have a numbered list for those steps (level 1).
> Point 1 checks if everything is here "* tool x, * tool y, * tool z"
> The tools don't have any order - so I'd like to use simple bulleted lists.
> Voila - bulleted list inside numbered list.

What came to mind, reading your example, is that it's easy to switch back
and forth between UL and OL while editing (that is, if the user changes
their mind). 
For your example it would suffice to do:

# point one
** item one
** item two
[...]
**item ten
# point two
# point three
[...]
# point ten

But I'm splitting hairs here... it's just as simple to do mixed [#*]
anyway, and we're in agreement. Whether my example works is an issue of
testing :-)

> I'm not sure I'm for a 100% oop approach - I'll give this some more thought.

When I set out in December, I decided on a non-OOP approach at the time
because I didn't fully understand the Wiki problem yet. I read once that
you don't really understand a probem until you've solved it once, and I
would like to think I've solved it now... 

There have been times in the last few months where I found myself wanting
a DB object and a page object, because objects are easier to work with
than a data structure and function library (sometimes).

OTOH, good OO design is *hard*. I've had to work with some really *bad* OO
designs (in Perl, at the NYT) and it can be a total nightmare. This is the
single most compelling counterargument I have: PhpWiki is a scripted Web
application that is completely procedural in design, fairly small, and
easy to maintain. For a lot of users, webmasters, sysadmins, and
programmers that means it's easy to tinker with. Not a lot of people know
OOP and OOD.

I think I am definitely in favor of a DB class, somewhat in favor of a
page class, and I'm not sure about anything more after that. I'd like to
see some proposed classes and we can discuss it. (I wonder if we can model
the classes in the Wiki?)

sw

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