[pmwiki-users] PageList Project

The Editor editor at fast.st
Tue Jan 30 12:04:11 CST 2007


On 1/30/07, marc <gmane at auxbuss.com> wrote:
> The Editor said...
> > On 1/28/07, marc <gmane at auxbuss.com> wrote:
> > > Why? I know it's an obvious question, but better to ask why you believe
> > > a time limit is necessary; what purpose does is fulfill?
> >
> > Well perhaps nt much.  But I do delete these pages after the time
> > limit so I don't have a bunch of these temp pages filling my wiki.
>
> Bah! Extra admin. Be gone ;-)

Ok, I see your point!  I just don't really feel like reworking all the
code...  Too busy with hg's at the moment.  : )  When I get the urge
I'll come back and learn hashing. And try it out. Seems very useful...

--snip--

> In general, I think that's why some of us don't use Zap. It's much
> easier to keep general functionality outside of recipes - loosely
> coupled - rather than within. That way, the functionality can be used
> more broadly and can easily be swapped in and out (strategy, facade and
> factory patterns, amongst others) or extended (decorators, etc.).

Well, while I do wish others would help me to improve the code, I
understand their reluctance. ZAP is really a system, or an approach to
PmWiki.  I like it, but it's a bit unorthodox (comes from being a
creative non-programmer!). I should add however:

1. One of my design goals was to make powerful php like applications
available to non-programmers without having to know a word of php.
ZAP does that pretty well.

2. I still am very deficient in certain areas of programming.  I don't
even really know what you mean by an object, and a class--well forget
it (for now).  So while I'd like to help develop simple reusable
objects, I'm actually still a bit handicapped...

> One advantage of a Zap-type approach, as I understand it, is avoiding
> having an explosion of action handlers, but that could be implemented if
> needed. It would make sense for a discrete lump of functionality.

Well actually, the advantage of ZAP is a theoretical one.  It dawned
on me pretty early on that virtually all user interaction with a site
is through a form.  So if you had a good forms processing engine, you
should be able to do about anything.  I simply set out to build an
engine that had all basic core web functions available.

In other words, if a person can learn the ZAP syntax (not really as
hard as people make it sound), an admin can do about anything he wants
without recourse to php or config files.  Just forms markup.  Which
makes simple cut and paste forms a snap.  That was my specific goal.
It doesn't help with the goal you mention below, of course.  And the
cost of this approach, is that more experienced programmers probably
won't buy into the system.  They want tools, not a toolbox.  :(

> But this kind of makes my point: that it would be more fruitful for us
> recipe writers to write loosely coupled functionality - obviously I
> prefer objects. We could then exploit each other's code at a slightly
> lower level, that, because of encapsulation, would be simple to use -
> because knowledge of the implementation is not required. I can dream :-)

If you can suggest ways I can cooperate with your dream, be sure to
let me know.  I've toyed with releasing a ZAPlite recipe which did
nothing but set text vars, and could probably do it in less than 100
lines. My excuse has been not wanting to maintain two separate
recipes, but the truth is--I just have a hard time cutting out all
those useful things I worked so hard to build in!!!  And I guess, I
keep hoping a few more programmers will see the possibilities of a
system like ZAP and buy into the toolbox.  If that happened, we could
find many ways to make ZAP even better, I'm sure.

In the mean time I will continue to try and help out with specific
tools here and there on the mail list as I'm able.  (I plan to release
the hg recipe as a completely separate recipe, unrelated to ZAP).  And
maybe I'll put out a quick ZAPlite if you think that might be
valuable.  Appreciate your insight Marc!

Cheers,
Dan



More information about the pmwiki-users mailing list