Cory Gwin

I was working on a jQuery plugin the other day and ran into an issue that made me think I should write up some notes on a very common jQuery plugin issue.

One of the key components to a healthy jQuery plugin is the ability to run it many times on a page. The way the plugin is structured can make this happen or keep it from happening properly, here is a key tid bit. Lets look at this very simple loading grapic plugin

(function($){  
 $.fn.loadingGrapic = function(text) {  
    return this.each(function() {
		var	ajaxImgObj = 'loader2.gif';
		var obj = this;
		if(text) {
			var displayText = text;
		}else{
			var displayText = "Updating Profile...";
		}
		$(obj).html(" + displayText + '');
   	});  
 };  
})(jQuery);

(function($){ 
})(jQuery); 

Self instatinting function that passes in jQuery as a parameter then redifines jQuery as $ in this function, this is passed in at the very last line of this code. This is odd as it is backwards the parameter (jQuery) is actually called before the function($) wrapping a function in ()(parameter) is the same as calling it and passing a parameter.

$.fn.loadingGrapic = function(text) {

Defines the name of the plugin in the jQuery namespace loadingGraphic is the name of this plugin $(“selector”).ladingGrapic

return this.each(function() {

this.each is used to run the function against multiple selectors, so the user may select more then one dom element with there jQuery selector by comma delimiting them. This is a key line of code to make sure that each item selected is run through your code.

var	ajaxImgObj = 'ajax-loader2.gif'; 

Ok now the real important part. Note the var at the begining of this line if Var is not place in front of the new variable then it will become a global variable, this can cause issues as the variable will not be changed per a selection but all selections made with this plugin will be changed if this variable changes, this is not an issue in this case because it is just an image location, but if by some chance we wanted different images for each selector and we did not have a var element, then each time it changed every element this function has been called on would changes at the same time. So there you have it, bottom line it is always best practice to put var in front of new javascript variables, if you don’t they will become Global variables. Sometimes you need Global variables, but keep that trick in your back pocket for those instances.

So I decided to install wordpress today and play around with it.  I have to admit I have always been an expression engine fan and have never gave it a second thought.  However, I am interested to learn a new CMS so I thought I would give word press a crack.  

So far so good, the install of WordPress is rightfully famous.  Talk about easy to setup! I had it up and running in about 10 minutes, would have been 5 but I got a phone call half way through. The install gave me a working blog out of the box that is fairly attractive.  

My first glance through the back end was an interesting engine.  I think the biggest difference between EE and WordPress is there initial setup, I feel like WordPress is much more friendly when initially up and running, this is largely because it feels like there are way less options.  I can see how this would be good for many people, it has the ability to be extended to be more of a CMS that expression engine is out of the box.

I don’t have much experience with themes yet so I don’t feel like I can do a true comparison yet, but my initial reaction is that WordPress feels very stripped down and great for smaller sites and projects while EE seems to be more suited for larger sites with lots of sections containing many articles.  Now before any hard core word press people attack me, I am well aware that WordPress can be extended to be a full featured CMS and I would be interested in that functionality.  Maybe I can become a convert we will see, initial reaction is that is seems like a solid offering that that really benefits from a large community of plugin developers. The UI is nothing short of elegant and strait forward, I am looking forward to seeing more.

Do you know PHP and are looking for a job? http://www.authenticjobs.com/jobs/6110 We are hiring!

When the lead pianist of the band gives you ear plugs, you know sh**s about to get real!

48 hour film fest entry http://www.ericjensenonline.com/Eric_Jensen/Videos/Entries/2010/7/18_48_Hour_Film.html

I was working on a project today with page elements that were 100% wide. I added a box shadow to the header element as soon as I did this, I realized the width of the page expanded.  The browser rendered the shadow as an element that was in the overflow of the page, Firefox and Safari both seem to add a scroll bar no matter how big the view port is.  Here is the code in question:

box-shadow: 5px 5px 5px #aaa;
-moz-box-shadow: 5px 5px 5px #aaa;
-webkit-box-shadow: 5px 5px 5px #aaa;

The first thing I tried was trying to move the shadow directly below the box by changing the offset.  This seemed to help but did not resolve the issue.

box-shadow: 0px 5px 5px #aaa;
-moz-box-shadow: 0px 5px 5px #aaa;
-webkit-box-shadow: 0px 5px 5px #aaa;

So in order to avoid this you need to add a little style declaration to the body element.  By applying:

body {
overflow-x: hidden;
}

The scroll bar is removed and the issue is resolved.

My home is now a video production studio #48hourfilm http://yfrog.com/0vcljqj http://yfrog.com/0uza3cj

It is official there will be a cyclocross race in Madison!

I have been working a lot on a smart phone site lately.  This offers a number of different things to consider when building these sites.  Users can be on a number of different devices, browsers, internet speeds and of course situations.  Dealing with this variance of devices poses some interesting design choices and technology choices. 

Browser support on these devices is actually kind of a high point.  When we started building the sites we looked at some numbers to see what we would need to develop for. Not to our surprise the large portion of this audience is on Safari or another browser that is based off the web-kit rendering engine. The other browser that seems to be dominant in the market is Opera mobile.  This making working on a mobile browser a lot like what developing on the web will be like in say 3 years when we no longer will have to support IE7&8.  These browsers all support CSS3, HTML5 and ECMA5 to some level.  Of course there is a few bad apples in the bunch, IE for mobile phones is nothing short of abysmal and Blackberries do not have full javascript support and often keep your scripts from running.

A major feature of most mobile sites is a automatic redirect. I am lucky enough to be working with sites on a CDN that supports automatic redirects based on user agent. Using some simple redirect rules can help to point the user to a separate mobile environment.  What I have found is that however you setup your redirect rules you will need to think of a way to give user who are receiving links to pages optimized for what ever system they are on. Sending a user on a PC to a mobile site will not be the optimal browsing experience for that user.  There are a number of ways to handle this and each is different depending on your development environment which I can probably not speak to.

The iPad has added an interesting twist into mobile development. The user agent is not the same as the iPhone, however we have know way of knowing whether the user is on a wi-fi connection or a 3g connection.  Knowing this information would help us to decide which site to serve them, without it a judgment call needs to be made.  I have decided to leave it up to the site owner and gather more info.

Deciding how much info to pass to a user is also a tough consideration.  Users on the edge network will be greatly affected by this choice.  One trend I have noticed on sites is to use lists of content and letting the user decide when they would like to see more of that type of content, upon a user’s request doing an Ajax call to load more of that type of content seems to be a good way to let the user determine how their bandwidth is spent. 

As you can see building for the mobile web has up’s and downs currently.  It reminds me a lot of building sites in the 90’s where the speeds where low, although we don’t have to deal with tables and weird browser specific code. As ATT starts charging more for bandwidth I am of the consideration it is a socially responsible move to lessen the graphic size of our sites for these devices.  I do however wish the browser/deivce developers would expose methods that would let use web developers know the users network configurations at time of page request.

At la fête de marquette watching the Occidental Brothers