jQuery can cause a little confusion when you’re first working with it. Once you understand the difference (and similarity) between collection methods (known as ‘methods’ in jQuery docs) and static methods (known as ‘functions’ in the jQuery docs), all the dual use and duplicate function names suddenly become clear.
Let’s talk a little about the .data() method and how it can be accessed. As stated in the jQuery docs, you can assign data to any element via the collection method like below:
// collection .data() method
jQuery('#myId').data('myInfo', { item : 'has a value' });
// and access that data like so:
var getData = jQuery('#myId').data('myInfo');Pretty useful. Now you can associate element specific data in the jQuery cache object for retrieval later. However, this isn’t the only way to get to this information, you can also access it (read & write) via the static method. That would look like the following:
var getStaticData = jQuery.data( jQuery('#myId').get(0), 'myInfo' );
// alternative
var getStaticData = jQuery.data( document.getElementById( 'myId' ), 'myInfo' );The difference here is that jQuery stores the key as the actual element, not the jQuery wrapper for that element. So the following would fail.
// will fail because provides the jQuery object wrapper for this element
var getStaticData = jQuery.data( jQuery('#myId'), 'myInfo' );Of course, you would never want to actually access the .data() method statically, because the collection method does a few things under the hood to make sure everything is working as expected. For example, when retrieving data a ‘getData’ event is triggered, as well as some basic error handling. Regardless, it illustrates an interesting difference and similarity between collection methods and static methods in jQuery.
You can take a closer look at the .data() method by downloading the jQuery 1.3.2 source and taking a look at lines 1367 for the collection method and 1274 for the static method.
jQuery has an awesome feature known as the context argument. It’s pretty lightly documented, but it’s extremely useful. Basically, it let’s you do selectors within a specific context. Let’s look at an example.
<div id="myParentId">
<div class="childOne">This is the first Child</div>
<div class="childTwo">This is the Second Child</div>
<div class="childThree">This is the Thid Child</div>
</div>The above is just a simple XHTML scenario.
// basic selector at the top level and cache in a variable
var pid = jQuery('#myParentId');
// select the first child in the context of the myParentId
jQuery('.childOne', pid).bind('click', function(event) {
/* do stuff on click to the first Child */
});
// select the second child in context of myParentId
jQuery('.childTwo', pid).bind('mouseover', function( event ){
/* do stuff on mouse over for the child*/
});This is an overly simplistic demonstration of context, but as you can see, it’s essentially like the .find() method. Of course the above could easily be accomplished using many different methods including ‘:first‘ or ‘.eq(index)‘. However, if you are caching your jQuery objects as Dave Artz suggests in his jQuery performance rules, the context argument is super useful.
Take your life stream anywhere on the web with my recently completed jQuery FriendFeed plugin. It’s a simple little JavaScript plugin that displays everything you pipe into FriendFeed plus comments made via FriendFeed. It’s super simple, and super useful.
The implementation is very easy. Just include jQuery 1.3.2 and the FriendFeed plugin on the page via a script tag. You can get both files on the jQuery site linked above. Then you just need to instantiate it. The entire thing might looking something like this.
<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
<script type="text/javascript" src="jquery.friendfeed.js"></script>
<div id="activityStream"></div>
<script type="text/javascript">
var options = {}; // optional second parameter to override $.friendfeed.defaults values
jQuery('#activityStream').friendfeed( 'username', options );
</script>Check out this demo I am using on my homepage. In the release on the jQuery site, I have also included some very simple CSS. The way the JavaScript is developed, you will be able to override everything. I make it simple by setting up a defaults object that can be manipulated via the second argument.
Additionally, you can replace or alter any method or value found in the $.friendfeed object by merely leveraging $.extend(); Look for more in depth documentation and usage in the near future. Or, if you want to share your samples, leave a comment below.
Published on
September 11, 2009 in
General.
So my friend Dan just got me… He IM’d me that he got an email from Biz Stone, read the whole (short) conversation on his blog here.
Back in January of this year, I took down the foto eBook site and stopped offering the software for sale. There are less than half a dozen copies of it floating around in the wild. As I read a post on A VC this morning about learning from your failures, I thought it would be important to finally be a little more self reflective on why foto eBook never took off and what I have learned.
There are a lot of reasons why foto eBook failed. For the last year or so, I have always tried to pin it on market conditions, but I think I’m finally ready to come clean. I think there are two reasons it failed: My heart really wasn’t in it and I wasn’t willing to let the software grow to meet the consumers needs. The idea of foto eBook was something that I found really cool right as I made my exit from Journalism and into Web Development, but it was mostly my back-burner, get rich plan, while I toiled at a major corporation.
That’s pretty much been the hardest thing to admit to myself, but without my heart really in it, foto eBook suffered from a lot of problems that could have been easily overcome. For instance, several potential clients passed on the product because it didn’t support video uploads. Something that wouldn’t have been overly difficult from a technical perspective to support. Also, several people wanted more custom control of the UI. Again, that wouldn’t have been impossible to support either.
Instead of addressing consumer needs, I was focusing on several other ideas, only putting about 100 hours in a year, hardly enough to grow a fledgling software product.
Ultimately, I have always wanted to build a product that has the chance to become viral. That’s what Digi Whack could be, though I’m not holding my breath and I think I understand what keeps it from having explosive success. I’ll keep trying my hand at different ideas until I either run out of time or money, or both. But I think I’ve learned two very important lessons from the failure of foto eBook. Build products you’re incredibly passionate about, and let your users help guide the way forward.
Check out the known copies of foto eBook:
