phpwiki-talk

Re: [Phpwiki-talk] Displaying diffs

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

>Yes and yes, and it's an idea I've played with (in my head at least).
>Doing it by diffs is somewhat awkward though... what would be cool is to
>store the pages in a format that preserves the change information somehow.
>Outside of XML though, I haven't had any ideas how to preserve this info.

A very interesting idea!  In the database, tag each line with which version
number in which it originally appeared.  Then a display similar to (but
hopefully far less cluttered than) the 'annotated' source view produced by
the SF CVS  browser could then be produced.  (I.e. "recent" additions or 
changes could be highlighted, and perhaps annotated with the author's name.)
(My guess is that deleted text would not be shown in this display.)

An example of SF CVS 'annotated' source can be found at:
  http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/phpwiki/lib/editpage.php?annota
te=1.15&cvsroot=phpwiki

Another, simpler, option which has been in the back of my head for a while
now, is just to fix things so that the diff output gets transform.php'ed.
Then one can create a "unified diff" (with infinite context) which will be
the transformed page with changes since the last version highlit.
(One VersionHistory is added, changes since any particular archived version,
could be highlit.)

-----

In other news:

Arno: I greatly appreciate your  comments in the JeffsDatabaseAPI
pages of the PhpWiki.  I've responded to most of your points/questions,
and would be interested to know if you've been swayed at all.

Steve & Others: I look forward to your comments as well.  There's no huge
rush, but it's clear that a fair amount of back-and-forth (and 
around-and-around)
dialog will be needed before any kind of consensus can be reached.  So it
would be good to at least "check-in" with your initial reactions/thoughts
fairly soon.

Also, feel free to suggest alternate database API's (possibly completely
different) (or based more closely on the current API) if that's what you
think we should be considering.



Also, I'm happy to report that Sandra (my wife), Lucy (my dog) and I (along
with most of the rest of Seattle) seem to have survived yesterday's rather
large earthquake in fine shape.

Jeff 

Re: [Phpwiki-talk] Displaying diffs

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

On Thu, 1 Mar 2001, Malcolm Ryan wrote:

> I was just reading Jeff's responses to Arno's comments on the API. Since
> they were scattered throughout the page, and I didn't want to scan through
> the whole page to find them, I read them in 'diff' mode. But, of course,
> I missed out on all the context, and the formatting. This lead me to an
> idea:
> 
> Would it be possible to add a different kind of 'diff' mode, which showed
> the whole page but highlighted the recent additions? (Or, if we had
> version histories and user authentication, highlighted the changes since
> I last read this page?)

Yes and yes, and it's an idea I've played with (in my head at least).
Doing it by diffs is somewhat awkward though... what would be cool is to
store the pages in a format that preserves the change information somehow.
Outside of XML though, I haven't had any ideas how to preserve this info.

~swain

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

[Phpwiki-talk] Displaying diffs

[Malcolm R. <mal...@cs...>]

I was just reading Jeff's responses to Arno's comments on the API. Since
they were scattered throughout the page, and I didn't want to scan through
the whole page to find them, I read them in 'diff' mode. But, of course,
I missed out on all the context, and the formatting. This lead me to an
idea:

Would it be possible to add a different kind of 'diff' mode, which showed
the whole page but highlighted the recent additions? (Or, if we had
version histories and user authentication, highlighted the changes since
I last read this page?)

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-1814

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

[Phpwiki-talk] Re: installing phpwiki

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

From the look of it, there is some problem with how PhpWiki determines
what version of PHP your site uses. I see:

HTTP/1.1 200 OK
Date: Wed, 28 Feb 2001 19:18:41 GMT
Server: Apache/1.3.12 (Unix) ApacheJServ/1.1.2 Rewrit/1.1a
FrontPage/4.0.4.3 PH
P/4.0.3pl1
X-Powered-By: PHP/4.0.3pl1
Connection: close
Content-Type: text/html

Unfortunately PhpWiki will try to use the dba_* library instead of the
dbm* library with any PHP version 4 or later; it's possible PHP 4.0.3 has
poor support for the dba_* functions, or it wasn't compiled in (more
likely).

I think what we need to try here is force your Wiki to use the dbm*
library. You can edit lib/config.php and set the database to "dbm" instead
of "default" (assuming you haven't changed it) and try again.

Let me know if it works...

~swain


On Wed, 28 Feb 2001, David Novogrodsky wrote:

> Dear Sir,
> 
> Thank you for contributing to the open source movement. I 
> am looking forward to using a wiki on my web site.
> 
> I downloaded your software yesterday (version 1.2). I tried 
> to install it into my personal website. 
> www.novogrodsky.net. I FTPed the contents of the unziped 
> file to this directory:
> http://www.novogrodsky.net/phpwiki
> 
> I pointed my browser at the directory and nothing happened. 
> No error message and no visible page.
> I also tried http://www.novogrodsky.net/phpwiki/index.php, 
> still nothing, no error and no page.
> 
> I installed the program by first untarring it on my Mac and 
> then uploading the entire contents to my web hosting 
> company. Could the problem be phpwiki does not have the 
> authority to create the pages it needs to?
> 
> Sincerely,
> David Novogrodsky
> 

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

Re: [Phpwiki-talk] What should I do?

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> There are numerous features I'd like to implement for my Wiki.
> 
> I think most of us are in agreement about what features would be nice to add.
> (Version history is at the top of my list.)

The problem is that VersionHistory would require the drastic db change. 
but haven't looked at this yet.

UserPreferences are a similar hot topic. 
now I have a cookie with username,email,state,realm and now also
notifications, 
but this can get very large.
imho better would be to store only a small numeric id at the client cookie and
the 
rest in a database table.

completely unfinished:
http://xarch.tu-graz.ac.at/home/rurban/acadwiki-1.3.4pre/viewsrc.php?show=lib/userauth.php
http://xarch.tu-graz.ac.at/home/rurban/acadwiki-1.3.4pre/viewsrc.php?show=schemas/schema.mysql

> But nobody seems to like my coding style, so at this point I'm afraid (or too
> polite) to touch the code in the main branch of the CVS --- I particularly
> don't want to make a large change (eg. new database API).

I like it. Sometimes you just need classes.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] how to enable html

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

On Thu, 22 Feb 2001, Didier Bretin wrote:

> Hello,
> 
>   I'm with the 1.1.9 version, and I can't find where I can allow the use
> of html. Can you help me ? :o)

To enable HTML, you only have to uncomment one block of code in
lib/transform.php. It looks like this:

/* If your web server is not accessble to the general public, you may
allow this code below, which allows embedded HTML. If just anyone can
reach
your web server it is highly advised that you do not allow this.

      elseif (preg_match("/(^\|)(.*)/", $tmpline, $matches)) {
         // HTML mode
         $html .= SetHTMLOutputMode("", ZERO_DEPTH, 0);
         $html .= $matches[2];
         continue;
      }
*/


Just strip out all the comments and you can then insert HTML this way:

| <table>
| <tr><td>blah</td></tr>
| </table>

by putting a bar  | at the start of every line.

If you want to go much further than that you can change the rules in
transform.php (not for the light hearted!) to use HTML instead of Wiki
markup.

cheers
~swain

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

Re: [Phpwiki-talk] What should I do?

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

Jeff,

I apologize again for my strong words (esp. about the comments).
I hope we can find a compromise.

> I think most of us are in agreement about what features would be nice t=
o
> add. (Version history is at the top of my list.)

Right.

> A few weeks ago, Steve posted a request for discussion of how to fit
> (among other things) version history into the database API.  I posted
> my idea (the jeffs_hacks API).

I'm sorry for my lack of time devoted to phpwiki during the last two week=
s.
Some other tasks required my full attention.

I'll look at your API on the wiki today and give my comments. We should=20
have this thing sorted out in a day or two. Then implementing version=20
history should be no problem. (this is option 5: we agree on the api and=20
you code :o)

/Arno

Re: [Phpwiki-talk] What should I do?

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

On Tue, 27 Feb 2001, Jeff Dairiki wrote:

> I think most of us are in agreement about what features would be nice to add.
> (Version history is at the top of my list.)
> 
> But nobody seems to like my coding style, so at this point I'm afraid (or too 
> polite) to touch the code in the main branch of the CVS --- I particularly 
> don't
> want to make a large change (eg. new database API).
> 
> A few weeks ago, Steve posted a request for discussion of how to fit
> (among other things) version history into the database API.  I posted
> my idea (the jeffs_hacks API).   Other than complaints about my coding
> style there has been frustrating little discussion on how to implement
> version history.

This is not unusual for the project though. It's taken a long time to
reach agreement on the features since we all hack on PhpWiki part time.

> I don't mean to sound pissed off --- I'm not, I'm just a little frustrated.

Completely understandable; and I commend you on your great diplomacy. I
was afraid our annual OO vs. procedural debate would have put you off
completely.

> Option #1 is my choice at the moment (after all, that is what everyone else
> does to get features they want into their own PhpWiki); however, I would be
> interested in hearing your input on the matter before I commit to it.
> 

I need some time to look over your API again. I won't really have time
until tomorrow night or Thursday though. Is that OK?

~swain

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

[Phpwiki-talk] What should I do?

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

I'm in a quandry.

There are numerous features I'd like to implement for my Wiki.

I think most of us are in agreement about what features would be nice to add.
(Version history is at the top of my list.)

But nobody seems to like my coding style, so at this point I'm afraid (or too 
polite) to touch the code in the main branch of the CVS --- I particularly 
don't
want to make a large change (eg. new database API).

A few weeks ago, Steve posted a request for discussion of how to fit
(among other things) version history into the database API.  I posted
my idea (the jeffs_hacks API).   Other than complaints about my coding
style there has been frustrating little discussion on how to implement
version history.

I'd like version history soon.  I'm willing to do the work to get it. 
(I've already done it once in jeffs_hacks.)

So what to do?

1. Just hack away by myself.  This means basically fork my own private
   version (which will look a lot like the old jeffs_hacks-branch.)
   I'd be perfectly happy doing this, however it seems seems a shame,
   since the whole reason for my fork would be to implement features
   that it seems many people are interested in.
   (I think it is unlikely that much of this would make it back the
   main branch: witness jeffs_hacks-branch.)

2. Officially fork the code.   Maintain (a new) jeffs_hacks-branch,
   either as an official branch of PhpWiki, or as a separate project.

3. Screw-em-all (:->) and just hack away on the main branch.  No,
   I'm not that type of guy.

4. Wait for Arno (or whoever) to implement version history (on the assumption
   that this is going to happen reasonably soon.)

I don't mean to sound pissed off --- I'm not, I'm just a little frustrated.

Any above the above options would be fine with me.  Truly.

Option #1 is my choice at the moment (after all, that is what everyone else
does to get features they want into their own PhpWiki); however, I would be
interested in hearing your input on the matter before I commit to it.

Jeff

Re: [Phpwiki-talk] Misc. comments

[Hollosi A. <aho...@xm...>]

Hi all,

Reading responses from Jeff, Steve and others I'd like to clarify my
point:
my main issue is not necessarily about adding too much new
functionality.
I for one would like to see things such as version history included as
well.
Also, I'm no big fan of making templates too fancy, but if it is well
designed, so be it.

My main point is "ease of use" (mentioned by Steve):

> admins: PhpWiki should be easy to set up and administor.
> hackers: PhpWiki should be easy to understand and modify.
> users: PhpWiki should be easy to use for writing hypertext.

If we keep this goal in mind, then it should be no suprise that adding
new features has to be done with care. I think that one main reason why
open source is (still) working if the project grows larger is
modularity.
I.e. a program should have a modular design and people should be
responsible
for different modules. This requires that we think about design *before*
we
implement stuff. phpwiki is not algorithmically challenging - coding is
easy. Making good design is a challenge.

Furthermore, it should be easy for new hackers (or for ourselves) to
grasp
the big picture of phpwiki. That means that we should have a clear
design
with __very few__ core data structures or objects. Currently these core
objects are $dbi, $pagehash, and WikiTransform. Wether they are written
as
real objects or as data+functions is just a matter of taste -- I don't
object making them real objects.

My statements about phpwiki getting too fancy are mostly related to
coding
style - not necessarily to functionality. A good example is include_path
vs.
$phpwikiroot. Also, I think we should pay more attention to commenting
the
code. Comments about functions, plus maybe a comment at the top of the
file
giving the big picture of what's happening should make it easy for
people
to find their way around. 

To that extend I  suggest that noone checks in stuff unless it is
commented.
For example, I saw that Jeff(?) changed the way tokenizer functions
work.
Yet, the comments were not changed to that effect. Keeping comments upto
date is easy if you check/modify comments every time you make code
changes.
If way wait for the big cleanup session before a release then updating
comments is a royal pain ITA. Exactly how much comments are needed
should be discussed in our coding guidelines.


/Arno

P.S: I just thought of a nice comparison: coding and Jazz (or music in
general). Imagine a Jazz quartett of geniuses (pick your personal
favourites).
Everyone is a wizard, everyine can play elaborate, highly sophisticated
melodies, or show off their mastery of the instrument. Yet, most of the
time
they hold back and play apparently "simple" stuff. Only when it's their
turn
for a solo, they really show what they are capable of. Take coding: if
you
are a real master then strive for writing elegant simple code which
everyone (even mere mortals) can grasp easily. This is the real
challenge.

[Phpwiki-talk] Wiki:HtaWikiBrowser

[Reini U. <ru...@x-...>]

Store this src as WikiBrowser.html, load it into micorosoft internet explorer
and use 
it to immediately display various pages per hotkey. phantastic!

  http://xarch.tu-graz.ac.at/autocad/wiki/WikiBrowser

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Misc. comments

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

and now, part two:

On Thu, 22 Feb 2001, Arno Hollosi wrote:

> Otherwise all you needed doing would be testing for $phpwikidir/locale/....
> Next point: people like Pablo combine phpwiki with other applications. They 
> might make use of include_path as well. How big are the chances that there 
> is another lib/config.php, lib/main.php, ... To avoid collision we would 
> have to rename either the files to wiki_* or the directory to wiki_lib/*
> Both look not attractive to me. Why mess with this stuff? include_path is 
> not as straight forward as $phpwikidir. What are the benefits?
> I don't see any. As for cons, see above.

We haven't considered making PhpWiki easy to integrate with other things
so far, and I don't intend to start now. Anyways any coder who would
undertake such a thing can just rename the files for now.
 
> Ok, maybe I have to be more precise. I don't like your style of OO.
> Don't take this as personal offense. I think you are a great programmer, 

Second that...

> > The $pagehash can, I think, truly benefit from becoming a bona fide
> > object.
> 
> This is the one I strongly argue against. Currently $pagehash is a set of 
> variables which can be modified easily *throughout* the code. Once you turn 
> $pagehash into an object phpwiki becomes a completely different application.

Hmm. Could you elaborate on this a little, Arno?
 

> > 2. The SF task list has been growing at a seemingly exponential rate. 
> 
> Only because it's on the task list doesn't mean we have to implement it.
> Steve uses it as kind of wishlist - not as a definite TODO list.

Also many of the things on the task list are little things, like renaming
the database tables.

> > PS: Hey!  What's wrong with emacs?  What do you use/suggest?
> 
> I don't know of any good php development platforms. It's even worse if you 
> have lots of classes and stuff.

This is a well known deficiency of PHP.

> That may be true for the db api, but not for general discussions. I don't 
> like having to check many places for information - a mailing list is easy, 
> everything is in one place and it's pushed at me (instead of pulling it 
> from webpages). I think there's a reason why 99.9% of all open source 
> projects have mailing lists as their primary communication medium.

I created one page (NewDatabaseApiAndSchema) in the hopes that we could
limit our discussion there, but I was naive and should have stated my wish
to contain this thread on one Wiki page (since by not quoting parts of an
email, context is lost).

> And yes, I think it would be healthy to establish some development goals 
> and guidlines for phpwiki. Implementing new features is fun. But without 
> clear goals we end up writing a big, bloated app capable of doing just 
> about everything, but so complex that not anyone is really going to like it 
> (and so far away from WikiPhilospohy that noone will recognize it as a wiki 
> anymore). And maybe some coding guidelines should be discussed as well.

Coding guidelines are on the task list. Again, if you look at the task
list, it's all doable and really the end-all, be-all a Wiki can be. At
heart it will still be a clone of the Portland Pattern Repository, but it
will also serve as an elaborate hypertext system for whiteboarding ideas.

> Compare pwiki and phpwiki - I think the reason why people choose phpwiki is 
> that it's so simple to install, customize, and extend. Once you take these 
> properties away phpwiki has lost it's appeal. Interestingly enough people 
> who are attracted to phpwiki because it's so simple are the first ones to 
> propose extensions to the functionality.

Such is the nature of programmers... you being one of them, since I never
intended to port Phpwiki to MySQL, but you changed my mind. Look where we
are now! ;-)

So: the discussion is about the features we want to implement. I think
there are a few I added that are really just wishes (like page types,
which would add a lot of complexity), some that are going to be rarely
used (like hosting multiple Wikis off the same install base), and some
that are really, really important (good version control and user
authentication). State your piece.

~swain


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

Re: [Phpwiki-talk] Misc. comments

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

OK, I've put off weighing in on all this, so I'll start with Jeff's reply
to Arno:

On Wed, 21 Feb 2001, Jeff Dairiki wrote:

> - the rush for new wiki markup (tables, picture floats, ...) -- I don't 
> like that at all.
> 
> I'll stay out of this one, except to say: I wanted simple tables, so I added 
> them.
> (And you're the one who added footnotes! :-) )

I loathe HTML tables. We've now added them after countless requests to do
so, the markup is simple, so let's leave it at that.

> 
> >- ...I don't like messing with the include path. Instead I suggest 
> > ... including all other files with "$phpwikidir/lib/filename.php".
> >Much easier to understand, less things to mess around. ...
> 
> Hmm. I respectfully disagree.  ini_set("include_path", "/some/where") seems
> pretty clear to me.

I side with Arno on this one. What we've been doing so far has been
satisfactory; in fact, we've previously renamed all the files, and them
moved them all into a separate directory. Bear in mind, Jeff, that this is
not a criticism of you or your choice (you have the best of intentions)
but I found having three different types of included files confusing. Then
again maybe that's why I publicize releases and update documentation
mostly ;-)


> >- the phpwiki code gets more and more complicated. That's against one of 
> >our primary design goals (at least we had this goal some months ago).
> 

And still is. I won't bother finding my post from months ago, since I can
remember these core values quite distinctly:

PhpWiki strives towards ease of use. Writing hypertext should be easy,
safe and fun. To that end we strive for three levels of "ease of use" (one
for each kind of "user"):

admins: PhpWiki should be easy to set up and administor.
hackers: PhpWiki should be easy to understand and modify.
users: PhpWiki should be easy to use for writing hypertext.

I don't think we've ever strayed from these goals. Right now we are in
pre-alpha times, where everything is open to questioning as far as
architecture goes; but remember these three kinds of users as you write
code, and always assume what you are writing is hard to understand.

No matter what the version of PhpWiki, be it 1.0, 1.2, 2.0, 7.0 or 13.0,
it will always do the following:

* untar and it works (on DBM)
* you can immediately start creating pages with BumpyLinks

After that it's all frosting on the cake, to use an old American
coloquialism.

> > * config.php -- why do we need FindFile(), FindLocalizedFile() etc.
> > we didn't need these functions before. What makes them necessary now?
> 

Hmm.. I thought I answered this above, so as you can see, I'm really
confused! :-)

> >There are other places as well. Keep the code simple. Fancy stuff should be 
> >removed and the code kept clear and easy.

Clarity is one of the three C's they teach in college. (What were the
others? Correctness, Completeness? Damn my cheap state college education.)

> >- about the templates: some are proposing to make them more sophisticated.
> >I argue against this. The end result is (after adding loops etc.) 
> >reinventing PHP or other HTML-embedded languages. 
> 
> True, but we are inventing a (hopefully) simple HTML-embedded language.

Ick. There is no such thing as a simple language. Look what happened to
javascript. Worse: C++. I doubt Kernighan ever thought C would be where it
is today.

> I would argue that if one is to have templates at all, they should be there
> to provide a clear separation between the design and programming of the page.
> As it stands some things (like ###RELATEDPAGES###) have their layout set 
> in PHP code, while others are layed out in the template files.  Adding
> a new "theme" to a current PhpWiki more than likely requires editing some
> PHP code.

I see your point... 

> What do the current templates provide now that couldn't be just as easily
> provided by straight PHP files consisting of mostly HTML interspersed
> with things like "<?php echo $RELATEDPAGES; ?>"?  At least this would
> provide the opportunity to intersperse larger chunks of PHP code
> to generate tables and such.  (Answer in part to this question: one
> can not (I think) capture the output of an include("template.php") ---
> it always gets spewed straight to the client.)

yes, partly, but even after the release of 1.0, people were having a very
hard time customizing the look and feel b/c the parts of the pages were
scattered throughout the PHP code... Arno made it very easy to change the
overall look, and if people really wanted to change the look of the search
boxes, well, they can learn PHP then ;-)

But, I must say this is a problem not limited to PhpWiki, nor PHP, but to
JSP as well, and any solution that exists in the web server space. That's
why the JSP crowd invented template engines and even then it's not a
perfect solution.

So, in the end: no matter what we choose (pure PHP solution, full blown
template language, or something inbetween) we will never be satisfied and
neither will the users. Don't despair.

> >We had some discussion about this some months ago - dig it up in 
> >the list archive.
> 
> I tried, but haven't found anything particularly deep yet.  Geocrawler
> keeps periodically crashing my Netscape, which makes it difficult.

That archive sucks. It's hard to search for things. But then, it's free.


And now on to the jihad ;-)   :

> >- object orientation: I know Jeff likes OO, I don't.
> 
> I guess that "easier/harder to understand" is very much a matter of personal
> opinion.  I view the database backend as a thing.  A thing upon which
> one can perform certain actions, some of which produce other things

I think I can state this in a way we all agree:

A simple application, well designed, will be easy to understand whether
it's written in procedural or OO languages/techniques.

A large system will be hard to understand, regardless of the design. One
can only understand so much of a given system. For me, PhpWiki has already
passed the point where I can understand the whole thing (for example, the
internationalization features are a mystery to me). BUT: since they are
modular and well maintainted by Arno I don't have to worry about it. You
can have modularity in either OO or proc. We already have both.

Now: a small application badly designed, whether proc or OO, is hard to
understand. The logic is not clear, or the code is not commented, the
variables poorly named, etc. When I worked at the New York Times I had to
work on two extremely poorly designed and implemented systems (in Perl),
and I will say bad OO is slightly worse than bad proc.

Let's let the design methodology debate end there, then.

I was calling for some objectification of PhpWiki in the 1.1 tree. My
idea: database and maybe page are objects. Each object itself contains no
other classes, just data and methods. I think this will slightly simplify
design and implementation.

Contrast this to Jeff's branch, which as I recall, had over 50 classes.
Maybe I'm old and slow but I just can't grasp such a system. So this is
the kind of uber wizardry that ordinary users (hackers in this case) are
going to be intimidated by.

Jeff's hacks branch is really an amazing work, but I am quite intimidated
by the code. It would take me a lot longer to hack on than what we finally
released for 1.2

> The $pagehash can, I think, truly benefit from becoming a bona fide object.
> There are many properties of a page which must be determined in a
> backend-dependent manner.  In some backends certain properties (e.g.
> backlinks) may be expensive to determine.  Different types of pagehash
> objects could be generated by the different backends.  They would all
> inherit basic and default methods from an underlying base class.

I think there is another way around this, and that would be to move things
like Best Incoming and Best Outgoing to another page, and the user clicks
a link like "Related Pages" to see this meta-info. But that's for another
thread. (The idea appeals to me b/c it will improve performance too).

> 
> >In short: keep it simply. phpwiki is getting too fancy for my taste.
> 
> This is a point on which a policy decision should definitely be made.
> (Or restated, if it's already been made.)

And I have :-)

> 2. The SF task list has been growing at a seemingly exponential rate. 
> (For the most part, not my doing.)  All kinds of fancy features have
> been discussed:  page types, user authentication, version history.  If
> or when all these features are added, phpwiki is not going to be a small
> program. 
>    No matter what your definition of "simplicity" is, maintaining it
> with all these features thrown in is not going to be easy.

Granted.. but then, it's not like writing a kernel or desktop environment.
If you look at the current task list, it's pretty much everything we *can*
do. If all the major features are implemented, PhpWiki will be done. There
is a wall we are approaching: the 4.x browser base and its limited
hypertext capabilities. Whatever comes next for PhpWiki will have to wait
until Xlinks and the like are implemented.

> 
> PS: Hey!  What's wrong with emacs?  What do you use/suggest?

I switched to Emacs last May, after using vim for seven years, and I'm
never going back! :-)

~swain

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

Re: [Phpwiki-talk] Misc. comments

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> - the rush for new wiki markup (tables, picture floats, ...) -- I don't
> like that at all.
> 
> I'll stay out of this one, except to say: I wanted simple tables, so I added
> them. (And you're the one who added footnotes! :-) )

I've added ImageLinks. I don't like inline images either and don't want 
to see any pornpics at my wiki. but navigation is much better this way. I have 
to sell this piece to reach critical mass!

> >- ...I don't like messing with the include path. Instead I suggest
> > ... including all other files with "$phpwikidir/lib/filename.php".
> >Much easier to understand, less things to mess around. ...
> 
> Hmm. I respectfully disagree.  ini_set("include_path", "/some/where") seems
> pretty clear to me.

Hmm, I'm with Arno. 
I already hardcoded all with 
  define('WIKIROOT', "/path/to/acadwiki/");
  include WIKIROOT . "lib/...";

> >- the phpwiki code gets more and more complicated. That's against one of
> >our primary design goals (at least we had this goal some months ago).

for me it looks still okay.

> >- about the templates: some are proposing to make them more sophisticated.
> >I argue against this. The end result is (after adding loops etc.)
> >reinventing PHP or other HTML-embedded languages.
> 
> True, but we are inventing a (hopefully) simple HTML-embedded language.

templating slows phpwiki down a lot. they more markup transformations and the 
more ###templatevars### the slower it will get.

I'll experiment with if-modified-since headers if it will make it faster.

I would also need some kind of "system" flag per page, 
where a handler is asked to generate some content and editing is forbidden.

* RecentChanges which should be generated dynamically.
* or the MetaWiki Search Engine.

without this flag it could be static. but it could also be just a MESSAGE.
for the admin stuff I would rather use a abrowse.html template, 
then doing all the ###IF###.

> What do the current templates provide now that couldn't be just as easily
> provided by straight PHP files consisting of mostly HTML interspersed
> with things like "<?php echo $RELATEDPAGES; ?>"?  At least this would
> provide the opportunity to intersperse larger chunks of PHP code
> to generate tables and such.  (Answer in part to this question: one
> can not (I think) capture the output of an include("template.php") ---
> it always gets spewed straight to the client.)
 
> >In short: keep it simply. phpwiki is getting too fancy for my taste.
> 
> This is a point on which a policy decision should definitely be made.
> (Or restated, if it's already been made.)

> 1. "Simple is in the eye of the beholder."  (See above.)
> 2. The SF task list has been growing at a seemingly exponential rate.  (For the
> most part, not my doing.)  All kinds of fancy features have been discussed:
> page types, user authentication, version history.  If or when all these
> features are added, phpwiki is not going to be a small program.
>    No matter what your definition of "simplicity" is, maintaining it
> with all these features thrown in is not going to be easy.

if not phpwiki then we'll have to do a fork. (hopefully not)
I need these features, and most other wikis already have them and more.
they make sense.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Misc. comments

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

this is already on the task list, but thanks for the reminder...
~swain

On Thu, 22 Feb 2001 ph...@de... wrote:

> On Thu, 22 Feb 2001 07:00:08 +0100, Arno Hollosi wrote:
> 
> 	One quick point, if I may:
> => I don't 
> => like having to check many places for information - a mailing list is easy, 
> => everything is in one place and it's pushed at me (instead of pulling it 
> => from webpages).
> 
> 	This may be one reason that some of us appliance drivers
> think that adding in an email notification option might be a good
> add-on, replacing the need to continually check each item in
> RecentChanges.
> 
> 	Thanks for all your hard work in phpWikwi - it really is
> a great little app.
> 
> 	Cheers,
> 
> 	- Don
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

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

Re: [Phpwiki-talk] Misc. comments

[<ph...@de...>]

On Thu, 22 Feb 2001 07:00:08 +0100, Arno Hollosi wrote:

	One quick point, if I may:
=> I don't 
=> like having to check many places for information - a mailing list is easy, 
=> everything is in one place and it's pushed at me (instead of pulling it 
=> from webpages).

	This may be one reason that some of us appliance drivers
think that adding in an email notification option might be a good
add-on, replacing the need to continually check each item in
RecentChanges.

	Thanks for all your hard work in phpWikwi - it really is
a great little app.

	Cheers,

	- Don

[Phpwiki-talk] how to enable html

[Didier B. <db...@in...>]

Hello,

  I'm with the 1.1.9 version, and I can't find where I can allow the use
of html. Can you help me ? :o)

Thanks

-- 
            .------------------------------------------------.
    .^.     | Didier Bretin, France | db...@in...    |
    /V\     |-----------------------| www.informactis.com    |
   // \\    |                       `------------------------|
  /(   )\   | Visit: http://www.multimania.com/cieexcalibur/ |
   ^^-^^    `------------------------------------------------'

Re: [Phpwiki-talk] Misc. comments

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

On Thu, 22 Feb 2001, Arno Hollosi wrote:
> 
> P.S: why doesn't http://phpwiki.sourceforge.net/alpha/ give the FrontPage?
> 

Hmm. Could it be... a bug? ;-)

Hmm. Ran the cron script and that brought it back to life.

~swain

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

Re: [Phpwiki-talk] Misc. comments

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

> >- ...I don't like messing with the include path. Instead I suggest
> > ... including all other files with "$phpwikidir/lib/filename.php".
> >Much easier to understand, less things to mess around. ...
>
> Hmm. I respectfully disagree.  ini_set("include_path", "/some/where")
> seems pretty clear to me.

Because of the usage of include_path you need FindFile & FindLocalizedFil=
e.
Otherwise all you needed doing would be testing for $phpwikidir/locale/..=
=2E.
Next point: people like Pablo combine phpwiki with other applications. Th=
ey=20
might make use of include_path as well. How big are the chances that ther=
e=20
is another lib/config.php, lib/main.php, ... To avoid collision we would=20
have to rename either the files to wiki_* or the directory to wiki_lib/*
Both look not attractive to me. Why mess with this stuff? include_path is=
=20
not as straight forward as $phpwikidir. What are the benefits?
I don't see any. As for cons, see above.

> The idea was to make clear distinctions between PHP code (located
> via include_path), language-independent data files (FindFile), and
> localizable data fiels (FindLocalizedFile).

Is the distinction by using different subdirectories not enough?

> >- about the templates: some are proposing to make them more
> > sophisticated. I argue against this. The end result is (after adding
> > loops etc.) reinventing PHP or other HTML-embedded languages.
>
> True, but we are inventing a (hopefully) simple HTML-embedded language.

The problem is: in the beginning it's simple. Soon you can think of more=20
and more fancy things and sooner or later you add them all until to the=20
point where your template language is as powerful as PHP. I'd like to=20
stress that again: I'm not totally opposed to your template stuff at=20
jeffshack_branch, but for wiki admins phpwiki it just gets more complicat=
ed=20
again: instead of 3 simple templates suddenly they are confronted with 14=
=20
templates. Sure it's more powerful, but does it need to be that powerful?
I argue that this is unnecessary bloat like in M$ programs. 99% of these=20
functionality will never be used. For those 1% of users who'd like to=20
modify e.g. the way search results look it is reasonable to force them to=
=20
edit the php files.


> What do the current templates provide now that couldn't be just as easi=
ly
> provided by straight PHP files consisting [...]
> one can not (I think) capture the output of an include("template.php") =
---
> it always gets spewed straight to the client.)

You could modify the template in a way so that
$x =3D file("template.php") - $html =3D eval($x) works.


> >- object orientation: I know Jeff likes OO, I don't.
> I guess that "easier/harder to understand" is very much a matter of
> personal opinion.

Ok, maybe I have to be more precise. I don't like your style of OO.
Don't take this as personal offense. I think you are a great programmer,=20
but you are clearly overdoing things. Take for example your transform.php=
=20
from jeffshack_branch and my one (the current transform.php). Yours is mo=
re=20
powerful, I'm sure. But mine __gets the job done__ too (maybe there will =
be=20
some minor modifications to it, but all in all it's ok). As for code=20
complextity, ease of understanding, ... I think that my version wins hand=
s=20
down (please correct me).


> The $dbi is a thing with a well defined set of methods which can be
> applied to it (DBLIB.txt).  Why not use the tools provided by the
> language to make this explicit.

I guess my objections are not so much in turning $dbi into a class.
I fail to see however, why we need classes like WikiLink.


> The $pagehash can, I think, truly benefit from becoming a bona fide
> object.

This is the one I strongly argue against. Currently $pagehash is a set of=
=20
variables which can be modified easily *throughout* the code. Once you tu=
rn=20
$pagehash into an object phpwiki becomes a completely different applicati=
on.


> There are many properties of a page which must be determined in a
> backend-dependent manner.  In some backends certain properties (e.g.
> backlinks) may be expensive to determine.  Different types of pagehash
> objects could be generated by the different backends.  They would all
> inherit basic and default methods from an underlying base class.

I fail to see why we need objects for this.=20


> 2. The SF task list has been growing at a seemingly exponential rate.=20

Only because it's on the task list doesn't mean we have to implement it.
Steve uses it as kind of wishlist - not as a definite TODO list.


> (For the most part, not my doing.)  All kinds of fancy features have be=
en
> discussed: page types, user authentication, version history.  If or whe=
n
> all these features are added, phpwiki is not going to be a small progra=
m.

I don't necessarily argue for a small program, but for a simple program.


> PS: Hey!  What's wrong with emacs?  What do you use/suggest?

I don't know of any good php development platforms. It's even worse if yo=
u=20
have lots of classes and stuff.


> PPS: The wiki (http://phpwiki.sourceforge.net/phpwiki.) might be a bett=
er
> place in which to carry out much of this discussion.

That may be true for the db api, but not for general discussions. I don't=
=20
like having to check many places for information - a mailing list is easy=
,=20
everything is in one place and it's pushed at me (instead of pulling it=20
from webpages). I think there's a reason why 99.9% of all open source=20
projects have mailing lists as their primary communication medium.


And yes, I think it would be healthy to establish some development goals=20
and guidlines for phpwiki. Implementing new features is fun. But without=20
clear goals we end up writing a big, bloated app capable of doing just=20
about everything, but so complex that not anyone is really going to like =
it=20
(and so far away from WikiPhilospohy that noone will recognize it as a wi=
ki=20
anymore). And maybe some coding guidelines should be discussed as well.

Compare pwiki and phpwiki - I think the reason why people choose phpwiki =
is=20
that it's so simple to install, customize, and extend. Once you take thes=
e=20
properties away phpwiki has lost it's appeal. Interestingly enough people=
=20
who are attracted to phpwiki because it's so simple are the first ones to=
=20
propose extensions to the functionality.


/Arno

P.S: why doesn't http://phpwiki.sourceforge.net/alpha/ give the FrontPage=
?

Re: [Phpwiki-talk] Misc. comments

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

Welcome back, Arno!

>- the new layout looks nice, but packing the whole page into a table just 
>to make it look nice is not really browser friendly.

Point taken.

- the rush for new wiki markup (tables, picture floats, ...) -- I don't 
like that at all.

I'll stay out of this one, except to say: I wanted simple tables, so I added 
them.
(And you're the one who added footnotes! :-) )

>- ...I don't like messing with the include path. Instead I suggest 
> ... including all other files with "$phpwikidir/lib/filename.php".
>Much easier to understand, less things to mess around. ...

Hmm. I respectfully disagree.  ini_set("include_path", "/some/where") seems
pretty clear to me.

>- the phpwiki code gets more and more complicated. That's against one of 
>our primary design goals (at least we had this goal some months ago).

More later. But, just in the way of explanation:

> * prepend.php -- why do we need this fancy error postponing?

I put that in because error/warning messages were making
for corrupt zip-dumps.  I suppose I hide it in libzip.php.

> * config.php -- why do we need FindFile(), FindLocalizedFile() etc.
> we didn't need these functions before. What makes them necessary now?

The idea was to make clear distinctions between PHP code (located
via include_path), language-independent data files (FindFile), and
localizable data fiels (FindLocalizedFile).  I'll admit that FindFile
and FindLocalizedFile should bear comments to that effect.

>There are other places as well. Keep the code simple. Fancy stuff should be 
>removed and the code kept clear and easy.
>
>- about the templates: some are proposing to make them more sophisticated.
>I argue against this. The end result is (after adding loops etc.) 
>reinventing PHP or other HTML-embedded languages. 

True, but we are inventing a (hopefully) simple HTML-embedded language.

I would argue that if one is to have templates at all, they should be there
to provide a clear separation between the design and programming of the page.
As it stands some things (like ###RELATEDPAGES###) have their layout set 
in PHP code, while others are layed out in the template files.  Adding
a new "theme" to a current PhpWiki more than likely requires editing some
PHP code.

What do the current templates provide now that couldn't be just as easily
provided by straight PHP files consisting of mostly HTML interspersed
with things like "<?php echo $RELATEDPAGES; ?>"?  At least this would
provide the opportunity to intersperse larger chunks of PHP code
to generate tables and such.  (Answer in part to this question: one
can not (I think) capture the output of an include("template.php") ---
it always gets spewed straight to the client.)

>We had some discussion about this some months ago - dig it up in 
>the list archive.

I tried, but haven't found anything particularly deep yet.  Geocrawler
keeps periodically crashing my Netscape, which makes it difficult.

>- object orientation: I know Jeff likes OO, I don't.

I guess that "easier/harder to understand" is very much a matter of personal
opinion.  I view the database backend as a thing.  A thing upon which
one can perform certain actions, some of which produce other things
(of a different sort).  It really just _screams_ "please implement me
as an object".  Maybe, in this case "object" is not the right word.
Perhaps "concrete class" and "class oriented" would be better terms.
The current code is already written pretty much in this manner.  The 
$dbi is a thing with a well defined set of methods which can be applied
to it (DBLIB.txt).  Why not use the tools provided by the language to
make this explicit.

The $pagehash can, I think, truly benefit from becoming a bona fide object.
There are many properties of a page which must be determined in a
backend-dependent manner.  In some backends certain properties (e.g.
backlinks) may be expensive to determine.  Different types of pagehash
objects could be generated by the different backends.  They would all
inherit basic and default methods from an underlying base class.

>In short: keep it simply. phpwiki is getting too fancy for my taste.

This is a point on which a policy decision should definitely be made.
(Or restated, if it's already been made.)

Some things to think about:

1. "Simple is in the eye of the beholder."  (See above.)

2. The SF task list has been growing at a seemingly exponential rate.  (For the
most part, not my doing.)  All kinds of fancy features have been discussed:
page types, user authentication, version history.  If or when all these
features are added, phpwiki is not going to be a small program.
   No matter what your definition of "simplicity" is, maintaining it
with all these features thrown in is not going to be easy.

Jeff

PS: Hey!  What's wrong with emacs?  What do you use/suggest?

PPS: The wiki (http://phpwiki.sourceforge.net/phpwiki.) might be a better
place in which to carry out much of this discussion.

[Phpwiki-talk] Misc. comments

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

Hi all,

I'm back. Some comments on recent developments:

- using stylesheets is a good idea - I'm a fan of stylesheets myself.

- the new layout looks nice, but packing the whole page into a table just=
=20
to make it look nice is not really browser friendly. I suggest using=20
stylesheets and <divs> for this layout trick. Thus older browsers are not=
=20
inconvinienced by a page table.

- the rush for new wiki markup (tables, picture floats, ...) -- I don't=20
like that at all. You are just reinventing HTML all over again. That is=20
*not* the purpose of wiki markup. Sure, the proposed markup is easy and=20
looks efficient, but for a newcomer it gets more and more complicated to=20
learn all these rules - heck, even I won't remember all markup and specia=
l=20
rules in a month if you continue at the current pace.

- the "exchange" of index.php and config.php is good. However, I don't li=
ke=20
messing with the include path. Instead I suggest setting a $phpwikidir in=
=20
index.php and including all other files with "$phpwikidir/lib/filename.ph=
p".
Much easier to understand, less things to mess around. See also next poin=
t.

- the phpwiki code gets more and more complicated. That's against one of=20
our primary design goals (at least we had this goal some months ago). It=20
will become harder to understand phpwiki and new users will feel=20
intimitated by the code. Examples:
   * prepend.php -- why do we need this fancy error postponing?
   Usually (in production), no errors should be displayed at all.
   Only for debugging one may wish to set error_reporting to E_ALL. And
   then I want those messages to appear whenever they actually happen - I
   don't care about the layout then.
   * config.php -- why do we need FindFile(), FindLocalizedFile() etc.
   we didn't need these functions before. What makes them necessary now?
   (see also $phpwikidir above).
There are other places as well. Keep the code simple. Fancy stuff should =
be=20
removed and the code kept clear and easy.

- about the templates: some are proposing to make them more sophisticated=
=2E
I argue against this. The end result is (after adding loops etc.)=20
reinventing PHP or other HTML-embedded languages. When I added ###IF### I=
=20
was very unhappy, but that was that. We had some discussion about this so=
me=20
months ago - dig it up in the list archive.

- object orientation: I know Jeff likes OO, I don't. Could someone please=
=20
explain me the advantages of using classes, when we use exactly *one*=20
instance of this class throughout the whole program? We don't even do=20
inheriting or other stuff. Just makes things harder to understand -- Also=
,=20
I don't consider emacs or other text editors a good development tool for =
OO=20
programs) -- these are also my *prime* argument against Jeff's db API. Th=
e=20
only thing I like about Jeff's API is the PageIterator - that one makes=20
sense.


That'll should do for now. In short: keep it simply. phpwiki is getting t=
oo=20
fancy for my taste.

/Arno

[Phpwiki-talk] Database schema redesign

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

Thanks to Jeff for all his work refactoring the site. There is a lot of
good stuff going on right now; see
http://phpwiki.sourceforge.net/phpwiki/index.php?CategoryNextWiki for
more.

Arno should be back now (and I'm sure he has lots of free time ;-) so we
need to reach a consensus on the next database API and schema.

I've been going crazy with the task manager at sourceforge, as you may
have noticed, and I've linked all tasks dependent on this thread. These
look like the most urgent issues, followed by what tables they affect (or
might affect, if we add tables):

* Unique IDs for Wiki pages (wiki, archive)

* Logging (new tables?)

* Version history/longer archive (archive)

* Link table + dangling references (wikilinks?)

* Email notification of page changes (subscribe to a page) (user prefs?)

* Authentication and user preferences (auth table? user prefs table?)

* Support multiple Wikis off the same installation (wiki, archive)


Things which might relate to this thread:

Page types (low priority for now)
InterWiki linking (add a new table or page?)
Revamped search (indexing pages for faster search?)

Rather than start a monster thread, we can discuss this on the Wiki
itself, or else we'll wind up with massinve quoting and replies. I've
repeatedly lost things in the past because the list was too active to
track them.

Do go there now and add your comments. 

http://phpwiki.sourceforge.net/phpwiki/index.php?NewDatabaseApi

Feel free to send notice to the list when you update NewDatabaseApi. (Be
nice and send the link.)

~swain

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

Re: [Phpwiki-talk] CategoryNextWiki

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

Oops, that's at
http://phpwiki.sourceforge.net/phpwiki/index.php?full=CategoryNextWiki

~swain

On Sun, 18 Feb 2001, Steve Wainstead wrote:

> 
> I started to organize a page linking to all the pages related to the
> development effort, when I found Jeff had already created a
> CategoryNextWiki. I'm marking a couple extra pages now. It all cries out
> for refactoring though.
> 
> ~swain
> 
> ...............................ooo0000ooo.................................
>    Hear FM quality freeform radio through the Internet: http://wcsb.org/
>                      home page: www.wcsb.org/~swain 
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

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

[Phpwiki-talk] CategoryNextWiki

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

I started to organize a page linking to all the pages related to the
development effort, when I found Jeff had already created a
CategoryNextWiki. I'm marking a couple extra pages now. It all cries out
for refactoring though.

~swain

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

[Phpwiki-talk] alpha site updated

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

Sourceforge recently fell back to the backup development server, for
reasons I don't know. This caused the loss of the new crontab I wrote and
the alpha site did not update yesterday and today.

I updated it by hand today and reinstalled the crontab.

~swain

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