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

Crisses crisses at kinhost.org
Mon Oct 9 12:40:38 CDT 2006

On Oct 9, 2006, at 12:51 PM, The Editor wrote:

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

Wow -- I did ok! :)  On an impossible topic.  ;)

Here's a real code-like example:

class Email {
	var $to = "";
	var $from = "myname at example.com";
	var $subject = "";
	var $body = "";

	function Set_Params ($to, $subject, $body, $from=$this->from) {
           //assign to class values
           $this->to = $to;
           //etc. ...

	// a couple internal functions not used outside the class
	function validate_email () {
           //validation in here
	function make_headers () {
           //create $headers including From - output to class variable
          $this->headers = $headers;

	function SendEmail() {
		// validate TO & FROM email addresses
		// create headers
		// send the email (should add custom From header too)
		mail($this->to, $this->subject, $this->body, $this->headers);

$email4Larry = new Email;
// set the properties
$email4Larry->Set_Params("larry at example.com", "Hi, Larry", $body);

Note I didn't put any error reporting, etc.-- it's just a quick  
example.  Of course you can have the class be FastData and only one  
of the many functions in it be SendEmail() but this gives you a real  
working example for something that might actually be useful,  
especially if the main application is sending emails from/to a  
variety of sources.  Email is a terrible example at the same time,  
because it's so bloody easy in PHP to actually send it.  But you can  
set up any pre-processing you want as part of the Class, such as the  
validation of addresses.  I think you can name Set_Params as Email  
instead and do:

$email4Larry = new Email("larry at example.com", "Hi, Larry", $body);

In this case the method/function Email is a constructor -- and can be  
passed parameters at exactly the same time as creating the instance  
-- so we've cut out the Set_Params step (see the php.net site for  
particulars to make sure my syntax is correct -- I'm winging this ;)  
But also note most of their code is PHP5 classes now, so it's become  

Still the constructor makes it almost as easy to create the headers &  
validate the addresses as it was to send via the mail() function and  
bypass those safe & pretty steps.  Note that you don't need a class  
to do this -- you can do it in a function.  But it's a nice example  
of how to make and use a real class, and most real world classes are  
far more complex.

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

Email in PHP is very easy.  But then again, email validation is  
another story.  You could add a hook for people to have their own  
email validator.  Some people might only allow name at something.tla or  
four letter acronym but in reality .museum is a real domain  
ending...it's a mess.

> 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 not sure how much overhead reading a file really entails...  so I  
can't say if it's worthwhile to just separate out even a 20 line  

BUT you could separate them by larger purposes:  Input functions,  
Output functions, Page functions ....  because if you're doing one  
you're PROBABLY not also doing the other.  You could be creating an  
excel export, importing an excel spreadsheet or form data, writing or  
changing a PmWiki page, but not usually doing all of the above.  So  
instead of separating them on a per-function basis, you could group  
them in a "likely to be used together" basis.

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

As long as there's a default already set that is both safe and  
easy...so the program doesn't break if someone leaves it out, but  
things can't be terribly abused if someone forgets to put it in.

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

When you come back to it 6 months later, you'll appreciate the  
comments ;)

> 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.  : )

It's processed lines, I think.


More information about the pmwiki-users mailing list