Tag: php

Form madness

Those who follow my blog may remember an earlier entry on form validation. I looked into some of the possible solutions those who commented provided, but other than Solar_Form, each was either trying to generate HTML, or not generating HTML was considered a plugin type of behaviour (i.e., the HTML generation was the norm, and not generating HTML typically added layers). Discouraged, I continued plugging away on my own solution which was incorporating Solar_Valid for validations, adding some filtering, adding the ability to load definitions from a file, and adding the ability to use callbacks for either filters or validation rules.

I got some code together, tried it out, and felt that either something was missing, or I was doing something a little wrong. I posted the code source, and asked Paul Jones for feedback.

After some initial flurries of emails with Paul asking for more detail, me providing it, Paul asking questions, me attempting to answer… Paul had me look at the source for Solar_Form. In doing so, I discovered what he was suspecting, namely, that we were trying to build something similar. Rather than continue on parallel courses, I decided to jump in and help in this aspect of the Solar project.

Continue reading...

File_Fortune 0.9.0 Released

File_Fortune has been released via PEAR.

Changes since the proposal include the addition of a static method for retrieving a random fortune from a list of files, the addition of a DocBook tutorial listing several usage examples, renaming the exception classes to conform to PEAR CS, some minor bugfixes, and some streamlining of the package definition.

Included in the release is an example script, phpFortune, that can be used on the command line to get random fortunes from one or more fortune files. Usage is:

$ phpFortune fortunes
$ phpFortune fortunes simpsons hitchhiker
$ phpFortune


Continue reading...

File_Fortune accepted to PEAR

What a way to start the day — I had an email from PEPR letting me know that my File_Fortune proposal had been accepted!

File_Fortune is a PHP OOP interface to reading and writing fortune files. It is loosely based on the perl module Fortune.pm, but modified significantly to better work with PHP file access methods, as well as to add writing capability.

I will be uploading my initial release shortly, probably as a beta or RC.

So, go fetch those Simpsons, Hitchhiker's Guide, and Star Wars fortune cookie databases and prepare to add random quotes to your site!

Continue reading...

Thoughts on form validation

I've been doing a lot of thinking on form validation recently. Among other things, I want to be using a standard set of tools for validating form input at work; I'm also rewriting the family website in PHP, and want to have consistency there as well. Finally, I truly buy into Chris Shiflett's top two security practices: filter input, escape output. Validation should always be done, and should be done rigorously; don't allow anything more than is necessary to get the work done.

I flirted briefly in the past month with HTML_QuickForm. Being an observer on the CGI::Application mailing lists, HQF looks like PHP's answer to perl's Data::FormValidator. HQF has a high frequency of posts on the php-pear-general lists. A lot of people seem happy with it. I decided to try it out as an example plugin for Cgiapp for the latest release.

My problem is that I want to be able to define form validation in a file outside my script. The reason for this is that as I extend and reuse classes, I often find that I can use the same general run-modes for a method… just so long as the form validation logic is separate. This allows me, for instance, to decide that in one application instance I will require fields A-M, but in another, I only need A-E (or vice versa). But it requires no changes to the actual application logic, as the validations are kept separately, and I have the application instance indicate which validation file to utilize.

Continue reading...

Notes on PEAR_Exception

I've been doing some thinking on exceptions, and PEAR_Exception in particular. You may want to skip ahead to read about how to use PEAR_Exception, as well as some of my thoughts on the class on first use. If you want the background, read on.

I've created a package proposal on PEAR for a package called File_Fortune, an OOP interface to reading and writing fortune files. I've been using a perl module for this on the family website for years, and now that I'm starting work on the PHP conversion, I thought I'd start with the building blocks.

In creating the proposal, I started with a PHP5-only version, though I found that I wasn't using much in PHP5 beyond the public/private/protected/static keywords. For error handling, I decided to try out PEAR_ErrorStack, as I'd been hearing buzz about it being the new "preferred" method for error handling in PEAR. (Honestly, after using it, I'm not too happy with it; throwing PEAR_Errors was much easier, and easier to manipulate as well — but that's a subject for another post — and exceptions were easier still, though more typing.)

The first comment I got on the proposal was the question: "Why PHP5?" (Paul wasn't too surprised by that reaction.) I thought about it, and decided it wasn't really all that necessary, beyond the fact that I'd need to take some extra steps to be able to actually test a PHP4 version. So, I did a PHP4 version.

Well, then some chatter happened, and a number of developers said, "Why not PHP5?" So, I went back to PHP5. And then somebody else said, "Use PEAR_Exception." So, I started playing with that, and we finally get to the subject of this post.

Continue reading...

ZCE - Results are in!

Got the official notification: I passed the Zend PHP Certification Exam, and can now report I'm a Zend Certified Engineer (ZCE)!

Zend Certified Engineer

Thanks go to my bosses at NGA for giving me the opportunity to attend php|Tropics, to Marco Tabini for offering the ZCE exam as part of the php|Tropics conference fee, and to my wife, Jen, and daughter, Maeve, for putting up with me while I studied… and being good sports about having to stay home while I went to Cancun. Hopefully next time I can take you along!

Continue reading...

PHP Application Documentation

Paul Jones has written an interesting piece about documentation in the PEAR project, in which he argues very convincingly for using wikis for end user documentation.

I actually think that last point bears repeating: using wikis for end user documentation. I talked to Paul about this issue at php|Tropics, and both of us use phpDocumentor quite religiously. However, API documentation is very different from end user documentation. And the issue with documentation at the PEAR project has to do with the fact that there are many projects with little or no end user documentation — which often makes it difficult for a developer to determine how a module might be used.

The often-cited barrier for this is that end user documentation on the PEAR website must be done in DocBook format.

Continue reading...

Search APIs

Twice in the past week I found myself needing to create or alter database search functionality in some APIs for work. In doing this work, I discovered some techniques that make this process much easier. In line with The Pragmatic Programmer, I found myself exploring the DRY principle (Don't Repeat Yourself), and looking into code generation (this time, SQL) — basically to exploit my inherent laziness and to make my job easier.

I thought I'd share some of the principles I've discovered for myself as I haven't read much information on the subject. Some of this may be rudimentary for some readers or those who work with more advanced abstraction layers (I suspect DB_DataObject may do much of this), but hopefully the information can be a useful reference for others (myself included).

Continue reading...

Planet PHP

I recently had an email exchange with chregu of Planet PHP regarding Planet PHP's blog selection. I've been subscribing to its RSS feed for over a year now, but was uncertain how blogs were selected — was it based on popularity of the developer, projects the developer works on (for instance, PEAR), etc. I felt that it was time for this information to be made public; it helps inform the readership why they're reading what they're reading.

And my exchange with him resulted in his Planet PHP FAQ blog entry, which hopefully someday will become a static page on the site. Additionally, I found out how new blogs get added, and am proud to announce I'm now in the lineup!

(Of course, the timing could not really be worse, come to think of it. I'm moving my family in to town this weekend (from our house in the Green Mountains of Vermont), and I need to make arrangements for hosting weierophinney.net in the interim while we wait for phone and DSL service — which won't be up for at least another week :-( I'm sure I'll figure out something… stay tuned!)

Update: corrected link to Planet PHP FAQ.

Continue reading...

PEAR and DocBook documentation

Sean Coates has posted a rant and a blog entry regarding DocBook and the various proposals on PEAR related to using a wiki for package documentation.

A little background is probably in order. Many PEAR developers feel that DocBook is needlessly difficult and provides a barrier to writing good documentation for PEAR projects; this is actually the most often-cited reason for lack of documentation for a PEAR package. Many actually create wikis that they then link to in a minimal DocBook tutorial as "full documentation".

One proposed remedy is to create a PEAR wiki for each PEAR package. A scheduled process would then transform the wiki markup to DocBook, HTML, PDF, whatever.

What Sean rants about is simply this: wiki markup is meant to be simple, and much code documentation would require specialized wiki markup. Additionally, DocBook is already meant to do the transformations required; it is a structured language that is meant to be processed into a variety of output formats.

While I agree with Sean's ideas in essence, I still feel that DocBook is a real pain to work with. PhpDocumentor offers some real convenience when documenting code: doc blocks can contain HTML, some simple inline elements like {@link} — and they make documenting a snap. But I just fail to understand why, when providing tutorials, a switch to DocBook is necessary. Whenever I use it, I find that I have to retool a set of tutorials I have, or somebody else has, already written in order to get formatting correct, and that I have to switch my thinking altogether to accomodate a new set of rules and logic.

Yes, DocBook is simply XML with a documented schema. However, I've never enjoyed XML. I find it too pedantic, I don't like having to escape out CDATA sequences in order to render HTML (and code, and XML, etc.), I don't like having to learn new DTDs for every project, and more. I feel for configuration, unless you have nested elements, there's no reason to use XML whatsoever. And when it comes to documentation, why use anything other than HTML? Since HTML is a subset of SGML (as is XML), there's no reason it can't be transformed to other formats itself — and for the majority of PHP developers, HTML is a known, while XML/DocBook may or may not be.

Whether or not DocBook is hard can be debated from here to eternity. The fact of the matter is that it is perceived as being hard to learn, and thus many PEAR developers are simply choosing not to bother. Why not give them a tool they can use easily? Maybe then the amount and quality of documentation on PEAR will improve.

Continue reading...