PHP-DSL cont.
May 15th, 2006, By Duncan Gough
PHP-DSL, a PHP Domain Specific Language, as seen previously on Suttree. What Domain is it Specific to? Web apps. I want to build a PHP dialect that makes doing the right thing the simplest thing for basic webapps. No Front Controller, no Framework, no Design Pattern, just plain old functional coding because, well, it will upset people. And that has to be a good thing.
So, creating a PHP DSL. Start with the basics – procedural programming, PHP embedded in HTML. Most developers include a config file at the top of every .php page, so that’s how we’ll include PHP-DSL. That gives you access to data sanitisation (two options, lazy (strip everything, probably using something like lib_filter) or explicit (intval() for numbers, strval() for strings)), and it gives you access to ‘obvious’ debugging using var_dump and the url as a command line. It also gives you access to a simple mysql interface, a wrapper around mysql_* with built in support for parameter binding (if possible) or mysql_real_escape_string at the very least. Maybe even use Pear::Cache_Lite as a nod towards scalability.
But why create a procedural library like this, why a DSL? Because, having written large chunks of Ruby code over the last few months, it’s the DSLspecific features of Rails that most feel like procedural programming. So much is taken care of on your behalf, by rails, that writing the business logic feels like either the closest you can get to natural language programming, or just like old-fashioned procedural embedded-php-in-html programming.
For example, in most ruby models you can just create highly readable strings that specify what you want that object to do:
class User < ActiveRecord::Base validates_presence_of :nickname, :password, :email validates_length_of :nickname, :within => 3..20 end
Ignore the top and bottom lines and you’re just reading something akin to plain-text. That’s not suitable for PHP-DSL, though. In PHP hands that’ll turn into a soup of design patterns in no time. PHP-DSL needs to actually strip out the top and bottom lines and leave me with just the plain-text bits.
Ruby makes it easy for you to do the right thing, the h() function for outputting dangerous content in html for example. It’s simple, short and easy to use. So, my attempt to start a PHP-DSL project is going to begin with a set of functions that acknoweldge two things:
1. PHP isn’t very good at being a DSL, I can’t write validates_presence_of functions without things looking messy
2. There’s a good chance that the vast majority of people using PHP are actually using it in an embed-and-be-done-with-it, procedural way. It just so happens that the minority of us, writing OO PHP, are a voal minority with access to blogs and forums.
So, with that in mind…. I’m going to read on and think about it some more. If I can call it a RoadMap, then that’s what this is:
PHP DSL, Version 1
1. Automagically sort out the regsiter_globals mess and sanitize all cookie/session/get/post variables.
2. Create a new echo/print statement, that htmlentities() stuff to prevent XSS attacks.
3. Include lib_filter or something similar to take care of both 1) and 2)
PHP-DSL, Version 2
1. Package up a databse wrapper, ideally using Adodb, for all database queries.
2. Make talking to the database as terse as possible. RESTfully terse.
3. Since 99% of beginner PHP webapps are just form interfaces to databases, create a sensible form handling process. Create validations rules that don’t suck, just like the ones in the Ruby example up there.
So there you have it. PHP-DSL, now codenamed Happy Hacking. Trust me, if we don’t do this, all the cool kids are going to pick Ruby on Rails to start programming the kind of web apps that will get them laid.
Update – I’ve just noticed these regexs in Cake that are define()’d as constants, making the code much more readable. That makes some of the simple validation rules a lot easier to implement. In fact, a whole bunch of this PHP-DSL project could be implement with judicious use of constants.
« Previous — Next »