Making do…thoughts from a Saskatchewan web developer

I wrote about my grandmother a while ago, so why don’t I bring up my grandfather with equal reverence for a bit?

Norman Dowdeswell was a Saskatchewan farmer who lived through the Great Depression. As such, he was somewhat resistant to buying something new when a bit of “fixer-upping” in the shop would result in getting something working again. He never threw anything remotely usable away. This was evidenced by his large piles of scrap metal in the yard and myriad jars and tins, filed with everything from used nails to retired drawer handles, lining the walls of his shop.

When we were doing farm work out in Grampa’s yard, my Dad and I would often have a chuckle at some of his make-do’s we discovered. Having a sore hip, Grampa made himself a cane for yard use by sawing off a hockey stick to the right length. He built a kids’ merry-go-round (known in our family as The Whirl-a-Gig) out of a big old tractor wheel. He made his own cab for the old Fordson tractor out of plywood and angle iron. And I couldn’t tell you how many items such as grain shovels which developed a hole at some period in their life and were later patched using braised brass.

So what does his grandson doing web design in Saskatoon draw from all of this?

1. New stuff can be a world of pain

Not only is new stuff an unnecessary driver of capitalism, it can be simply a recipe for heartache.

How many times have you upgraded your computer’s operating system for the Wonderful New Features it offers, only to discover that your other software and hardware ceases to work properly? What starts out as a free upgrade so often results in many hours and dollars spent on new software, driver upgrades, expensive dongle adapters, or new peripherals. And the old installation discs, manuals, and fully-functional hardware end up either recycled or in the landfill. Often there’s no going back.

Right now I am two OS versions behind on my laptop because I know if I upgrade, my whole Adobe Creative Suite will hit the toilet and I’ll need to upgrade that and start paying subscription fees. I’ve tried Illustrator CC on my machine and it is so slow as to be unusable. Are things good enough right now? You bet they are.

2. Sometimes new ain’t new enough

“What does it cost to migrate to WordPress?” These are words I often hear from people with perfectly good websites. Even when I could make a ton of money from an expensive upgrade, I’d much rather have a client get good value from what they already have.

Sometimes a user has a robust CMS such as Joomla, and finds the feature set is simply overwhelming. Often they don’t understand that Joomla is already preventing problems which are typical to other systems, and providing features they don’t have.

If the user needs simplicity, there are many options for easy editing in Joomla, whether it is custom administrator templates, using front-end editing, installing a blogging component, or simply having a training session. Good web developers should be training their clients properly when building a site, and stick around to guide their clients in managing it.

3. Know when to give in

I do my best to resist “the new” but the time will come when a major upgrade just makes sense. For example, I had a client with an older version of Joomla ask me if they should upgrade. For a couple years my answer was no, because there was no security concern. However, a security issue was recently uncovered which affected many old versions of Joomla. I was quick to recommend the upgrade.

My grandfather bought a new car in his later years. With his health declining, it just made sense to have a reliable vehicle for long road trips.

Thank you for reading this. I hope that 2017 will be a good trip for you!

 

 

New Confidant Website

I’ve had a slow couple of months business-wise, but the benefit of that is I can work on my own projects. I am happy to report that I have just completed a new website for myself. My WordPress blog (you are here) has not changed, but you will notice that my top-level site has been updated to be completely mobile-compatible using modern day technologies. My previous site used Flash for its primary experience and did have a mobile-compatible fallback but this was never ideal, especially as today’s browsers are making it more difficult to use Flash.

So—the new site is built using the UFront framework. This is a very interesting and useful tool because it uses the same Haxe source code which compiles for both client (Javascript) and server (PHP). The framework is able to cache resources such as the site template, and it builds pages client-side whenever possible. It will remotely load only the data it needs to build each new page. The result is that the site is super fast. If you watch your network activity as you browse my portfolio, you will see that each new page requires only a few kilobytes, and browsing previously viewed pages will have nearly no network activity at all. If JavaScript is disabled, the site looks identical and pages will be built server-side instead.

For graphics, the site detects high-resolution (e.g. “Retina”) devices and serves high resolution images to them if they are available on the server. The top-level site navigation features a single SVG graphic for the menu. The graphic is embedded in the site template, where it serves as a graphic library allowing me to have the same display code used for both the menu and the headers. Animation effects are achieved using only CSS3 transforms, which saves the user from having to download any JavaScript libraries.

Something I wish was different is that Webkit-based browsers like Chrome and Safari for desktop don’t render fonts nicely when perspective transforms are applied to page elements. I was able to remedy this fairly easily for portfolio items, but pages at the second level of my hierarchy are a bit fuzzy. My hope is that these browsers make improvements which remedy this for me.

As a benefit to the Haxe community and a thank you to other people who provided coding help, I have released my full UFront source code on Github.

Thanks for reading!

I Built a Joomla Component with Haxe

Tank on Mountain

Here is my code, and that’s me at the top of the mountain there, wondering what to do next.

In case you didn’t know, my favourite programming language Haxe compiles to PHP, and my favourite CMS Joomla is made with PHP. I’ve been longing for a robust user-friendly CMS done in Haxe for some time, but it’s been long in coming. So I built this Joomla component with Haxe by following the Joomla Project’s component tutorial, converting to Haxe as I went along. As far as I know, I’m the first person to ever do this so I’m somewhat pumped about that. I’m here to tell you what I learned and hopefully it benefits somebody.

The Compiler

If you browse my code, the first thing you might look at is the php.hxml file, which configures the compiler. You will notice that this file is very lengthy. This is due to the fact that when Haxe compiles a PHP project it creates a single PHP entry point which links to the specified main class. All the classes are filed away in a “lib” directory as separate files. This is great if you’re building your own stand-alone application, but Joomla is very prescriptive in the way components need to be structured. If you want to take advantage of the CMS’ advanced features such as template overrides and its built-in MVC system, you need to follow strict conventions in class naming, file naming and folder structure. I can’t explain all that here, but I’ve made a few comments in my code about it. You will learn from my php.hxml file that:

  • I have separate “main” class files which will cause Haxe to compile the files which Joomla needs, using the “–php-front” compiler option to specify the proper file name, and “–php-lib” option to ensure Haxe files its own stuff in a single lib location.
  • Even though I could specify the file name of the php entry point, I had little control over the code it contained. Haxe always generates a call to the constructor function which conflicts with what Joomla does, so I needed to search/replace that line with a simple include of the desired class. I used the “-cmd” option to call a PERL command which does the job easy and quick without needing a Haxe macro.
  • To make life easier I also included other -cmd options which remove ‘.DS_Store’ files on Mac (don’t want those on live site), copy the generated files from my development folder to my local server folder, and zip-compress the component for easy installation in Joomla.

If I had better skill at using macros I might look into better ways of generating the required files, but this seems to work for now.

Externs

The great thing about Haxe is that by using externs you can refer to non-Haxe classes without the compiler complaining. This is essential when developing for an existing PHP framework. Unfortunately these are very time-consuming to create by hand, so I relied on a couple different tools for generating these:

  1. Macro: A great macro by Samuel Batista (found in files called “PHP.hx”). I modified it to use an external configuration for file paths. In most cases I was able to generate a good extern by using a build directive at the top of a class which called the “generateExtern” function in the macro. To give the macro something to process, I needed to copy Joomla’s “libraries” directory into my own code folder. This made it easy for me to manually remove things like comments which interfered with the macro, and will prevent Joomla updates from breaking anything.
  2. Convertor: The PHP-to-Haxe conversion tool here. When the #1 macro was proving too troublesome, I would simple copy/paste the Joomla PHP class into the convertor in #2 above, and then hand-edit the results (see my externs for JObject, JRequest, JTable and JToolbarHelper).

As I discovered Joomla classes I needed to access, I would need to locate them in the Joomla libraries directory and then create the externs using the above methods.

Non-Haxe Stuff I Did

I could likely make a case for developing in Haxe rather than PHP in many circumstances, but it’s just not a good substitute for creating HTML, SQL, XML, or INI language translation files. There are also PHP files in the tmpl directories which are intended to be overridden by the user and so should be easy to read. These also need to follow naming conventions, so I chose to simply hand-code that PHP directly. JavaScript files might have been good candidates for using Haxe, if I had needed any complex ones.

Random Tips on Developing with Haxe for Joomla/PHP

The Joomla Project’s component tutorial was thorough but unfortunately written for Joomla 2.5 rather than 3.0+. When things weren’t working right, I usually had to refer to the php_error.log file to see what happened. I use MAMP on my Mac, which makes it easy to locate that file and open it using the Mac’s Console application. Once I knew where the error was, I would then open the offending PHP class to see if my Haxe code had generated the code I wanted. When an error was generated by Joomla rather than PHP, it would usually appear onscreen instead of within the log.

I would often use Haxe’s “untyped __php__” feature just to get things working, then convert that to pure Haxe once I knew it could work properly. I left some php commands as untyped because I wasn’t sure how to replicate them in Haxe easily.

I included cache directories in the component because Haxe will use them after the component is installed.

PHP Arrays do not automatically become Haxe arrays, and vice versa. When Joomla is feeding an array into one of your functions you may need to convert it using “toHaxeArray” from the php.Lib.

This component is missing some of Joomla’s built-in goodies such as ACL, trashing, and batch operations. I really just wanted a working component to show it could be done. I highly recommend becoming a Joomla expert before using this code for anything important.

All PHP code installed in Joomla needs to use a GPL license and needs to refer to it within the code. This would need to be added if you wanted to make something for the Joomla Extensions Directory. Your Haxe code can use other licenses because it would qualify as a “Tool”.

Where to go now?

I have dreams of making Joomla components with a complex front-end using OpenFL, and it would be nice to have a user-friendly backend for easy administration. Joomla includes good tools for producing JSON output and using XML-RPC, so that’s what I would rely upon if I ever went further with that idea.

Ideally I would want a Haxe Joomla development tool to have an easy configuration method that would generate all of the required Joomla files automatically such as this ant script does. Even better would be to have a rapid application development framework like Akeeba FOF. Unless I start doing lots of Joomla components this way, I doubt that this would happen.

As for now, I have climbed the mountain and am looking for a suitable target I can shoot from this vantage point. I hope my tank doesn’t get too rusty before the war starts.