2011 posts

JQuery UI Draggable and Droppable make it fairly easy to implement dragondrop on a web page. There are some things that are not easy to do with it though. One example is having a droppable accept multiple types of draggables with different responses depending on type, especially when added at different times (for instance, being attached by separate objects/scripts). The way JQuery UI is set up, only one droppable behavior set can be attached to an element, so doing

element.droppable({accept: ".type1",...});
element.droppable({accept: ".type2",...});

simply replaces the ".type1" options with the ".type2" options.

In a recent project, I needed multiple draggable types per droppable, so I created an object class to handle adding a new "accept" type and associated events to an element that is already a droppable. I do this using duck punching to overwrite the original event callbacks. The wrapper callback checks the draggable element to see if it matches the new "accept" value. If so, it runs the new callback, otherwise it runs the original callback. Every time a new set of droppable options is applied, a new wrapper callback is created that calls the previous, so that no functionality is lost. Perhaps not as efficient as a single function with an if/switch tree, but that would not be feasible for this use case.

Haven't been posting much at all, but I've not been working on web stuff any less. I'll give a bit of a synopsis of what I've been doing. This year I've been doing less new and interesting with HTML and CSS and more with JavaScript and PHP and database stuff, particularly the last several months. We've had one rather large project that requires mostly work in those areas. We are building a system that will use a JS heavy admin area based on Qooxdoo. The public side will use Symfony 2 with Doctrine for managing data. All three of those I've never worked with before and have had to learn as I go.

Qooxdoo is a full framework for JavaScript with a class system and a bunch of widgets that make working with it sort of like programming a desktop GUI application. It really extracts away from HTML/CSS and it can be frustrating knowing how to do something easily with those but not being able to use them. I don't care for the abstraction, and it would be unfeasible to build a non-JS compatible app with this approach. I do like its class system quite a bit though. It has a lot of features and gives a lot of functionality for free, such as firing events on property change and easy access to parent methods. I've been working on my own class system and would like to incorporate some of its features.

Last weekend I went to GiveCamp in Cleveland. GiveCamp is a weekend of developers and designers building sites and applications for various charities. There were like 202 people there, working in the Lean Dog boat and in the hallway of Burke Lakefront Airport. There were 22 charities, each assigned a team appropriate to their needs. 21 of the projects were completed or nearly so in the one weekend allotted.

My project was Cleveland Carousel. My team also included a designer named Greg and another developer named Jon Knapp, who kind of managed the project most of the time. We had continuous help from at least one of the Cleveland Carousel people at all times. We also had a couple dedicated project managers come help us out for a little while as well.

The clients had a simple WordPress site in running with four pages, but they want something with a lot more content and pictures and a custom design. They came well prepared with a detailed plan of what they wanted, allowing us to move quickly with our small team. They worked with Greg to come up with a design, worked to put all of the content in place, and gave us continuous feedback as we built the site.

jQuery makes it fairly easy to animate DOM elements. Animating a single-step animation on one or more elements is simple with the call of the animate method. Multi-step animations can be more complex because animations are run asynchronously, meaning that they will start running when called but the script will continue onto the next step before the animation is done. For these, jQuery has the ability to queue steps. jQuery automatically queues multiple steps on a single object and dequeues as each completes, so you don't have to worry about managing things and setting up callbacks. But for more complex animations where multiple elements are animated at different times or other functionality must be performed after an animation step, there is no automatic queuing.

A common practice for simple queuing is to use the "complete" parameter of the animate method or of other similar asynchronous methods that is a callback to be run when the animation is finished. This works nicely when there are a few steps. It becomes more unwieldy though the more steps you add. That is where queue comes in, allowing for adding of as many steps as you want without having to nest in callback after callback.

The ls command can have nice colors enabled to differentiate between file types…

At work I did my first fully ajax loaded, from scratch site, Block Bros. I used jQuery with my own library of "wrapper" classes for loading the ajax and animations between "pages". I had to write a lot of new stuff though and modify some of my library classes to get everything working smoothly.

It has been quite some time since I've posted anything, but I certainly haven't stopped building websites. One thing I like to find out from other developers is how they do things so I can compare them with what I do and take anything that I like of theirs better, so I'm going to share some of my current practices. I'll start with javascript, since I just built a javascript heavy site and want to share some more specific javascript stuff in later posts.

Base Library

To begin with, I use a namespace to store all of my javascript variables/objects in. This doesn't pollute the "global" window object with many variables and drastically reduces the possibility of collisions with other libraries. Since javascript has no actual namespaces, but it does allow for generic objects and the ability to add arbitrary attributes and functions to them, I just create an object and add everything to it. I use __ because it is small and quick to type, can't really be given any meaning based on the name, and probably won't be used by someone else.

The only other thing I put in the global namespace is the base object type I instantiate that variable with. I did this as an object so I could conceivably create multiple instances and so that I could declare it later in the file and have all of the site specific code at the top. I call it tmlib since it is my library. So a bare instantiation might look like this:

if(typeof __ === 'undefined') var __ = new tmlib;
__.cfg.whatever = "whatever";
__.scrOnload = function(){
	doSiteSpecificSomething();
}
/*----------
©tmlib
---------*/
function tmlib(){
		this.classes = {};
		this.lib = {};
		this.cfg = {};
	}
	tmlib.prototype.addListeners = function(argElements, argEvent, argFunction, argBubble){
		var fncBubble = (argBubble)?argBubble : false;
		if(!__.lib.isArray(argElements)) argElements = new Array(argElements);
		for(var i = 0; i < argElements.length; ++i){
			var forElement = argElements[i];
			if(forElement.attachEvent)
				forElement.attachEvent("on"+argEvent, argFunction);
			else
				forElement.addEventListener(argEvent, argFunction, fncBubble);
		}
	}
/*--init */
__.addListeners(window, "load", __.scrOnload, false);

Usonian income taxes are crazy complicated and a pain to deal with. They shouldn't be, especially for normal people: Only people performing complex income related activities should have any need for a tax accountant. There are so many modifiers to promote certain behavior and demote other, but it is very inconsistent and confusing and irrelevant stuff often has to be read through by people for whom it doesn't apply. Promoting behaviors is good, but it needs to be simplified drastically.

The destination of tax revenue should directly and rigidly define the destination of where it is spent. The destination should be related to the source as if the source was a customer buying services from the destination. Continue reading post "Taxes: Sources Define Destinations"