phpwiki-talk

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.

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

[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

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

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

[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

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

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

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