OO posts

Notes on Using PHP Class With Statics for Configuration

I will be talking about using namespaced PHP classes with static properties for configuration. Since my use was in relation to Symfony, it is important to note that the Config component should be used for everything possible, but that it can’t be used before it is instantiated.

Reasons to use namespaced static class properties for configuration:

  • A class can be defined in a file. When that file is included from elsewhere, the class is defined.
  • Once a class is defined, it is accessible anywhere after that point, regardless of scope. Like a superglobal.
  • Statics are variables set on a class rather than on an instance and can be accessed directly from the class. This means no variables outside of the class need to be set to work with the variables. Like a superglobal singleton.
  • Statics are not static and can be modified just like any other variables.
  • Static methods can control access and provide other behaviors you may want for working with your configuration.
  • Namespaces help prevent collisions of class names by essentially adding characters to a class name that make it less likely to be used elsewhere. With psr-0 / psr-4 autoloaders, the namespaces should be well controlled.
  • Variables can’t be namespaced, so classes (or constants or functions) are the only way to take advantage of their benefits.
  • Using constants and functions inside of a namespace is similar to static properties and methods of a class, except the constants are immutable and have limited data types, and there aren’t the niceties like self for the functions.
  • Being in PHP (as opposed to some config file format) allows use of __DIR__ (my primary need was for storing paths, and it wouldn’t be ideal to have to put in the full filesystem paths to things), string concatenation and other operations, and any other PHP behavior or values desired.
Continue reading post "Notes on Using PHP Class With Statics for Configuration"

tmclasses: my javascript class library

I’ve decided to take my JavaScript class system out of my more general JavaScript library, tmlib. It can now be found in my js-tmclasses repository. I felt it needed to be separated to make it easier to work on without the clutter of all of the other functionality in tmlib. It also will be easier for others to make use of, not being buried among a bunch of other junk and not having all of that junk in the default build file. This decision was made easier since I converted to using require.js a while back. I can include tmclasses in a vendor folder, pull into tmlib and attach everything to the same places in tmlib to provide the same interface as before, and it is basically the same as it had been usage-wise. The build is slightly heavier, but that is partly due to duplication of methods that I will eliminate or limit.

tmclasses is a fairly simple class system so far. It provides a method for creating ‘classes’, which in JavaScript are basically functions with properties attached to their prototypes. The feature set is basic, but I intend to add more to it to get some of the niceties of Qooxdoo’s class system. I like a lot of things about Qooxdoo’s class system, but found it hard

Usage

The heart of tmclasses is the create method. It is passed an argument with all of the configuration to create a class.

Continue reading post "tmclasses: my javascript class library"

Javascript: Closures, Objects, and Timeouts

I recently discussed two issues with closures in Javascript. I continued to improve my menu script by fixing some IE issues, then I moved everything into objects. By moving to objects, I ran into another issue that was basically a combination of the two issues discussed in the previous article. I did not immediately realize this however, for whatever reason, and spent some time figuring it out.

The issue was with setting a timeout that calls a method of the object the timeout is set within. The method is attached to “this”, but “this” changes scope in a “setTimeout” call (“this” becomes “window”). To pass the appropriate “this”, we create a variable pointing to this and then pass it to an anonymous function that returns another anonymous function which uses are pointer to “this” to call the desired method. Since my “setInterval” was attached to an event listener, it also had to be placed inside of the double anonymous function. It looked something like this:

class.prototype.functionName = function(argElement){
    var fncThis = this;
    var callback = function(fncThis){
        return function(){
            fncThis.timeout = setTimeout(function(fncThis){ return function(){fncThis.classMethod(); };}(fncThis) ,750);
        };
    }(fncThis);
    argElement.addListenerEvent("touch", callbackMouseout, false);
}

This was the only major issue I had putting my code into objects. The last time I had tried something similar, I had given up dealing with the timeouts, but this time I had more experience. Now I have nice, reusable OO classes for suckerfish menus, etc.