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