Categories
Work

SDES Template Engine

  • Type: Class
  • Language: PHP

Purpose

In our division, there are various entities we consider customers. Most of those customers cede support of their web environment to us, but some retain the right to have a full-time “developer” on staff to make edits. Unfortunately, there is crossover between sites we’ve developed and sites that these developers feel belong to them. This has been a problem for years; only now am I taking action programmatically. I got clearance to develop a simple PHP class/framework/engine to structure the basic data each of our sites require (title, subtitle, navigation, social networks, etc.).

Method

I wrote everything by hand, top to bottom, imagining our basic PHP sites as objects. These objects needed many small pieces, like the title, the associated department, and the contact phone number, but I considered larger items, like database connections, the page requested, and the layout/design of the site. I wrapped most of this data in a straightforward class that accepted changes to its properties exclusively via setter methods, exposed data exclusively via getter methods, and farmed settings out to a config.ini file.

Highlights

As every site was converted to this simple engine, it gave me the ability to wrap simple HTML blocks into helper methods. Now, every site has a standard way to print contact information, social networking URIs and buttons, footer information, and so on. It has been an easy bridge between design and development to save time and preserve a standard.

It also gave me a chance to develop a database class that preserves a single database connection via the singleton method (only allowing a single instance of the database object).

Takeaway

It feels like I’m creeping a little too far into custom-PHP land; I know we should be using something like Symphony or CodeIgniter and a templating framework like Twig or Smarty, but for this environment, where access to production is treated like a right and not something to be protected and given out sparingly, I needed something a bit more customized and esoteric. But rest assured this custom implementation will be trashed and swapped for some open-source framework as soon as our environment makes sense.

Categories
Work

LINK

  • Type: Website
  • Language: PHP
  • Framework: None
  • Authentication: Integrated
  • Data Source: SQL Database

Purpose

This project was largely self-initiated. As with many problems at UCF, my task arose from a former student assistant’s bad and incomplete code. Rather than tip-toe around it and poke and prod as necessary, I decided to take up a sprint to rewrite the database front-end and accompanying student-facing site.

Method

As we had yet to adopt a PHP framework, the CRUD for each table was developed by hand, with a few helper functions that matched httpPost values with SQL table columns for create and edit pushes.

Highlights

For the public event submission form, I was able to discover an API to UCF’s campus map, consume it as JSON, parse out the list of buildings, and make that a required choice for the event. Once the event was approved and posted, public users could then discover the location of the event through a link to the campus map.

As each event was displayable as both a master event and a single session of a master event, I was able to integrate each with a “Post to Facebook” and “Post to Twitter” button, allowing a social layer of connection to the program’s social networking presences.

Finally, we developed some icons that allowed event categories to be associated with a color, allowing users to quickly determine differences.

Takeaway

Sometimes, throwing away the remnants of a bad idea and starting fresh is the best way to go, despite the time commitment. The resulting application has survived with no changes for years now–a testament to the customer’s satisfaction with the user experience.

Categories
Work

FormProcessor Class (PHP)

  • Type: Class
  • Language: PHP
  • Framework: None

Purpose

As I tackled more and more UCF sites during my tenure, I discovered that each individual “webmaster” had developed their own server-side implementation for sending emails of basic web form data. Rather than continue to work around their own code, I developed a PHP implementation that generically wrapped httpPost data into a simple email.

Method

The first implementation of FormProcessor was a simple PHP class that had public properties (e.g., to, cc, and subject), some private methods to check for dangerous code (like email header injection), and a public method to send the email. Over time, the public methods have become private in favor of mutator methods, new helper methods have been added (including file attachments, filestream attachments, a development mode, etc.), and any specific stored information has been migrated to a config.ini file.

Highlights of Implementation

As complicated as it was to implement an email attachment method without a standard library, it is exceedingly satisfying to use that method in seconds now. Also, finally working with PHP in an object-oriented manner is a breath of fresh air.

Takeaway

At this point, I kind of wish I’d known about the PEAR Mail package, but I’m fairly proud of the implementation; it’s made it effortless for our web content updaters and designers to implement fairly powerful email operations without needing to know much (if anything) about PHP. It continues to make PHP development and deployment speedy and predictable, and it has been integrated into the Template Engine I built to standardize our layouts.