2013 posts

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.

Finished my third Cleveland GiveCamp last weekend. Another successful event. This year, my project was a new web site with more features for Bike Cleveland. We were doing well enough with that project that I was able to help another project Saturday night and Sunday, a web application for the Cuyahoga Valley National Park Environmental Education Center.

Bike Cleveland

Bike Cleveland is a bicycle advocacy group for the greater Cleveland area. They had an existing site that was in WordPress, but wanted it to be more engaging for members, allowing more involvement and discussion. Our group was composed of a team lead, four developers, a designer/ux person, and a learning teen with photo editing knowledge. Our client was good with WordPress, able to install plugins and what not, and generally understood what we were doing, so he was very easy to work with.

We started Friday night discussing what he wanted. We decided what was most important and what we could skip if time was short. He wanted to involve members with forums, an ability to submit events, forms to submit accidents and thefts, to have buttons to share things, and to emphasize ways to become involved with the organization. They also wanted the site to work on mobile devices so that people could use it from phones while out cycling.

I haven't been doing much with WordPress, since at Cogneato we have our own CMS. But a customer request for a WordPress site a while back and the upcoming GiveCamp which I will be participating in this weekend have rejuvenated my interest in working with it. Back when I was using WordPress more often, I had built a bare theme I used as a starting point, including for the Stearns Homestead site I was working on when I first started this blog. That was the WordPress 2.x era though, and the theme is now outdated. I decided to begin work on a new theme, making use of the new 3.x features.

I have learned a lot since building that theme, and wanted to bring in some of my new knowledge and coding practices to the new theme. I also wanted to put this one on GitHub, since I now have an account and others might find it useful. I still haven't decided for sure what I'll call it (for now it is TJMBare) and have more work to do, so it isn't on there yet, but hopefully will be by this weekend. Anyway, I wanted to mention some of the things I have done or will be doing with it.

Class helpers

I am putting all of my functionality and data into classes that in most themes is put into the global namespace. The classes will help group functionality and data together, making it easier to develop and to avoid collisions. Since WordPress doesn't yet require PHP 5.3+, I am avoiding using PHP namespaces, but am compensating by putting the equivalent on the front of the class names. Functions.php will just include the class files and instantiate what is needed. Child themes will be able to extend parent theme classes to change functionality.

I've been doing quite a few responsive sites since I first started into them. I like doing them. They are fun to build, requiring new techniques and a different way of thinking to handle different situations. I like the concept and I like looking at the sites. One recent fun thing was dealing with an image map. Scaling the image and coordinates would be a pain and very expensive. An alternative option is to replace the image with a select drop down when the screen is too small for the image.

Breakpoint detection

I don't remember where I found this method of dealing with breakpoints in JavaScript, but I've been setting the line height on the html tag with media queries and reading it with JavaScript to determine which breakpoint I'm in. This works with the 'em' based breakpoints I use. I convert the numbers to more descriptive names, such as 'small', 'medium', and 'large'. It looks something like this:

I went to my first real full length web development conference today, Rustbelt Refresh. It was a very good conference with good speakers and interesting topics. Finally something like this in Cleveland. I learned and got to thinking about various things. I was rather tired though after waking up so early and spending a whole day there. I will summarize / talk about each presentation, as sort of a minimal review, but primarily to store and cement what I've taken away in my mind.

Presentations

Eric Meyer: The Era of Intentional Layout

Eric Meyer is our local global CSS celebrity. I've gone to every local presentation he gave that I was aware of, which I think totals three with this one.

His talk started with a history of CSS layout, and how CSS never got a real layout system and the things we still use today are mostly hacks, limited in what can be done with them, and often create problems. To summarize this history: At first the web had no layout, and content just went with the flow. Then tables came in for tabular data. They quickly became used for layout because of the lack of alternatives, and soon made markup a nested mess that was difficult to maintain and impossible to change the layout without changing the site structure. Floats were added to allow content to flow around things like images, and quickly became usurped for layout. Since they were designed without layout in mind, they had a lot of problems in use for it, and a lot of creative hacks have been created to get around them, like equal height columns and zero height containers. Then came positioning, which was actually designed for layout, but had the problem of taking things out of flow and thus not allowing things to move in relation to each other, etc.

I've recently been working on reorganizing, cleaning up, and improving my javas…

It is a good practice to not pollute the global "namespace" (ie window in browsers) when creating JavaScript code, especially if it is to be reusable, to avoid collisions with other bits of code that may be used on a page. It is common to use objects as namespaces. You can say window.myLibrary = {} and then add whatever you want to that object with confidence of no collisions with other libraries as long as myLibrary isn't taken. Larger libraries will often have a namespacing function that will manage the creation of these namespaces, allowing them to be accessed if they already exist or created and then accesed if not, and easily handling multiple levels of depth. A simple example may look like the following:

namespace = function(_namespace, _scope){
	if(!_scope){
		_scope = window;
	}
	var _currentScope = _scope;
	var _identifiers = _namespace.split('.');
	for(var _i = 0; _i < _identifiers.length; ++_i){
		var _identifier = _identifiers[_i];
		if(!_currentScope[_identifier]){
			_currentScope[_identifier] = {};
		}
		_currentScope = _currentScope[_identifier];
	}
	return _currentScope;
}

Then you can do something like:

ns = namespace('myLibrary.mySubNameSpace');
jQuery.extend(ns, {
	'component1': function(){}
	,'component2': function(){}
});

I've been doing the more manual approach for my library, but have been desiring for a while to get more organized and streamline repetition by adding my own namespace function. I got to thinking about doing more with the namespace objects, so that they can perform operations on themselves once created. For example, they might be able to create and return sub-namespaces as well as easily extend themselves.