Knowing this higher level of abstraction - it doesn’t really matter if you use PHP/Ruby/Java/C# - it’s all the same then :)

One of the most frequent concerns I hear from students and readers when I teach PHP and write about it is that they often feel they’re being cheated from the “real” language knowledge when a solution I advocate involves using a PEAR module or add-on library. I think this worry is misguided, but it is nevertheless common. Folks often want to learn “PHP”, not a library or framework that sits on top of it.

So, part of the challenge is the meta-education that gets people comfortable with learning a particular toolset *plus* the language, not just the language. Doing this right involves making the concepts clear enough so that the learning is as transferrable as possible from one toolset to another — learning how and why to filter input and escape output in one framework should make it possible for the student to do the same thing, easily and quickly, with a new framework or toolset. We change jobs, change projects, do lots of things that require us to adapt to new conventions and libraries.

The other potential issue with this approach is that some brittleness is hidden under the bucket of the framework you plan to create and its necessary simplicity. It is tough to strike the right balance between doing everything that one considers the minimum necessary to ensure proper conventions and practices (such as data escaping input and output, proper sql injection protection, and data/presentation separation) while simultaneously keeping the framework bits simple *and* making it extremely clear to students which things they’re doing are part of core PHP and which are conventions and add ons that this curriculum happens to use. At a certain point, it may just be more straightforward to pick a popular framework and use that. It’s probably not going to be that much more complicated than anything homegrown and offers students the advantage of some knowledge that’s directly transferrable to their job or hobby projects.

All of these issues are not PHP-specific, but are, I think, more of an issue in PHP than with other languages since the community often prefers roll-your-own solutions rather than using existing code and that there is no clear winner for popular tasks that aren’t part of the core — tfor example, there’s no obvious framework that’s in the same position of dominance as Rails is for Ruby. So striking the right balance in teaching between “here’s *a* way to do some things that you’re definitely going to need but aren’t part of PHP out of the box” and “here’s *the* way to do those things” is tricky.

Best of Luck!

While at PHP Appalachia, I had the pleasure of meeting David Rasch, the founder of Triangle PHP, which meets in the Raleigh-Durham-Chapel Hill region of North Carolina. One night, by the campfire, David and I launched into a discussion about how newbi…