[pmwiki-users] Request input on soon-coming FAST Data release

The Editor editor at fast.st
Mon Oct 9 11:51:01 CDT 2006

On 10/9/06, Crisses <crisses at kinhost.org> wrote:
> I don't want to do that.  I want modules I can upgrade without breaking a
> site. I do understand that things would probably break from FastData2 to
> whateveryoucallit3 -- that's a major revision -- but I don't want them to
> break from upgrading due to a security fix.  I only hacked the code as you
> recommended so that it would create data pages that PageLists et al would
> work with.

This makes sense. I hadn't thought about it from the upgrade side.
That's actually the reason I switched from Drupal to PmWiki.  I will
try to find a better way.  My goal is to make the next release the
last to breaks forms--at least for a good long while.

> Otherwise I prefer to work in a separate cookbook recipe or in config.php.
> Another thing that's important to keep in mind:  Namespace.  I've been
> trying to keep the > vast bulk of my (newer) cookbook recipes within a
> function or class.  The problem is that > every time you create a variable
> you risk bumping into conflicts between your variable
> name(s) and those of other recipes.  This also goes for function names.

This is pretty amazing.  It sounds like a much better way to do this.
Where would I call the included modules--inside the class?  I'll
tinker with this some and see if I can't put all this in a class. It
doesn't seem too hard...

> I know this is probably confusing, so feel free to ask questions....
> Is that helpful?

Yes, you did a beautiful job explaining it.  Thanks!  I'll try and run
by a draft for you a little later to look at and see if I got the idea
correctly implemented.

> A good example of code that should be in an included file for your recipe is
> the FastData->Database functions.

Setting FAST Data up on a modular basis would perhaps allow other
people to develop modules that could be inserted easily enough, such
as database connectivity, which is not something I'm sure I really
want to tackle personally... Though looking at some of the past
database recipes, the code didn't seem to hard, or too long.

On the other hand, I'm looking at the recipe to see about other
natural modules. Emailing is one.  New member authentication is
another. File management functions a third. And misc stuff not often
used could be a fourth.  The problem is, because of how functions are
integrated, the emailer is only about 20 lines of separate code.
Authentication less than that. File management is only about 25, maybe
30 with a renaming. And I'm not sure how many functions would fit in
the misfit  catagory. The only one I see right off, is the uploader,
but it's only five lines.  So out of 500 lines less than 100 are
really dispensable.  And as I'm not noticing any performance problems,
it's perhaps not worth the trouble.

What about putting all the extra stuff in one "second" zip-booster include?

>> I'm still chewing on whether I want to split up the recipe into
>> modules or keep it all together.  Haven't come to a conclusion yet.

> I really do not want to edit your recipe when I download it.
> If I want to keep the recipe in tact, compartmentalizing it and only
> calling the needed functions is really the best way I can think to go about
> it.  Yes, it's more files to keep track of, but it also helps you think
> about how you've organized your code.

I think for now I'll just keep it all together so people can get
started using it right away.  If we need to modularize it, we could
try and do that later in a way that allows for a seemless upgrade.

The other option might be to group several like functions within one
conditional that could be enabled or disabled by default in the config
file. This might allow for example, one to disable file management, or
emailing capabilities except in specific groups.  It wouldn't shorten
the code, but could cut out a number of secondary level conditionals
and thus speed performance a bit.  It might also provide a bit of
extra safety. It would of course require an extra line to the config
file by the admin to unlock any features you might want to use.

> Now, if you need help looking at your code from a new perspective, I suggest
> you ignore the 500 line barrier and document the code -- a lot.  Then people
> can look at it, make suggestions to improve it, make suggestions as to how
> you could have it execute more smoothly, etc.

I will try to add more comments. I thought the code was easy enough to
understand, but then again, I have labored with it more than one
sleepless night.  To others it may not seem quite so intuitive. I
suppose comments don't really slow down processing time do they? And
if you don't count the comments, I can still add my ban/approve
feature and claim the code is under 500 lines.  : )


More information about the pmwiki-users mailing list