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=
?