My erstwhile mentor in Brienz taught me throughout our years working together that if a website functionality is worth creating, it’s worth creating so that it can be used in more than one project. Programme once, install many times. This is a credo I’ve maintained since I started programming for content management systems and one I try to pass on when working with other programmers.
There are many functions which are specific to a client, and making specialized code sufficiently homogenous that it can be used in many instances is sometimes far too complicated and far too expensive. But where I conceive a new feature, I do my best to analyze the requirement and determine if it’s multi-use.
An example of this is the Location Manager we use at !frappant, coded for TYPO3. The technical concept is based on original work by a predecessor, which was programmed around seven years ago for Best Western and implemented for their listing of Swiss hotels until recently.
By making the backend code and database logic homogenous, the same extension could be implemented (with a different HTML output and bespoke CSS rules) several times for Verkehrs-Club der Schweiz over the past few years: for their review references of Swiss ski resorts, for the Ride & Glide campaign to get people to travel to ski resorts by public transport, and for their guide on travelling around Europe by train.
By making the extension handle pure locations instead of more specific location types like sports destinations or cities, we can implement the extension wherever there is a requirement for managing or displaying a group of locations: whether they’re ski resorts, shops, cities, hotels, or affiliated companies.
Customization or project-specific code and output can then be tailored to the client’s requirements with much less programming overhead and much lower costs to the client.
Where extensive customization is needed, we again evaluate how the additions to the original code may be developed in a modular way. We add the new code either to the base TYPO3 extension, so that future projects profit directly, or as a project-independent secondary extension.
A good example is the Location Ratings extension, which extends the Location Manager with additional functionality to allow each “location” to be scored according to certain principles.
The basic Location Manager extension contains all of the administrative functionality and the database structure, which remains constant across all installations. Instead of giving database fields specific names like “resort name”, we built the data structure around common field names like “name” or “description”. Because multiple description fields are necessary, for directions or for details of sights to see at the destination, we built the database structure with homogenous names like “description1” and “description2”.
When it comes to project-specific customization, we use XLIFF files in a secondary extension to define field descriptors. “Directions” or “Attractions” for tourist destinations, or “Intermediate stations” and “Services on board” for a directory of train travel.
We then add Fluid templates and our own CSS and JavaScript to build the output for the website: again, using existing SASS mixins for elements obeying common layout principles.
Working in this modular way makes development much easier. Experts in front-end development can focus on the HTML and CSS, whilst backend specialists can develop and improve the basis extension.
A client needing a Location Manager need no longer spend thousands and thousands of francs on a solution for which we need dozens of hours to programme from scratch: instead, a lesser budget can be assigned and spent much more wisely on customization and integration to an existing website.
Less hassle and stress for the developers, and less hassle and cost for the client. Modularity is a win-win solution.
Leave a Reply