Adventures as an IT Monkey

The not quite personal blog of Robert Lynch, computer monkey. A mixture of insight, analysis, and wishful thinking on all things technological and beyond.

My Photo
Name: Rob Lynch
Location: Las Vegas, NV, United States

I am a web developer in the Las Vegas area. Currently employed as a PHP programmer at LV.net.

Tuesday, December 15, 2009

jQuery UI Draggable Revert Callback

While this functionality is built into jQuery UI as of this writing, it is not well documented that you can set a callback function for the revert option of a draggable object.

Advanced Draggable Revert functionality with a Callback Function:

jQuery UI provides us with a number of useful widgets and behaviors to allow us to build rich user interfaces. In this document I will show you how to better use draggable and droppable by adding a callback function to the default revert behavior.

For the sake of simplicity I like to think of draggable objects as pegs and the droppable objects as sockets.

The revert option of the draggable class can be modified to execute a callback function that allows for greater flexibility in it's operation. By default the revert option has the following possible values:

revert: 'invalid','valid','true','false'

Just to briefly co over what each does, the invalid option will cause the draggable object to revert back to it's previous position (the location it was in before the drag), if the draggable does not get dropped in a valid droppable.

There are a number of cases where we need to provide additional checks in order to determine if an object can be dropped in a specific location after the fact.

Consider the following code for a set of draggable divs given the class “peg”.



$(".peg").draggable(
{
revert: function(socketObj)
{
//if false then no socket object drop occurred.
if(socketObj === false)
{
//revert the peg by returning true
return true;
}
else
{
//socket object was returned,
//we can perform additional checks here if we like
//alert(socketObj.attr('id')); would work fine

//return false so that the peg does not revert
return false;
}
},
snap: '.socketInner',
snapMode: 'inner',
snapTolerance: 35,
distance: 8,
stack: { group: 'pegs', min:50 },
stop: function()
{
draggedOutOfSocket = false;
alert('stop');
}
} );

As you can see that we've replaced the usual string or boolean values given to the revert option with a callback function. The functionality is in this form, the same as using 'invalid', but it illustrates the concept well, because this is by far the most common usage case for revert.

The anonymous function takes one parameter, I've decided on calling it socketObj but the importand bit is that you know that one parameter is sent too the callback. This lone parameter will either be false if the draggable was not dropped into a droppable socket, or it will contain the droppable object if it was successful.

The action taken by revert is determined by what we return from our callback. In the example if the socketObj is false we return true, because we do want to revert position. Conversely if an object was passed to the function then we will return false so that our dragged object will stay where we dragged it.

Note that you can see there is a commented out javascript alert. I placed it there to express that this is a standard jQuery object that has all the usual methods you are used to dealing with such as attr() to read the attributes.

Some common things you might end up doing in this portion of the function would be making additional tests to see if you really want that element where the user dropped it, potentially reverting it (by returning true) even though the drop was valid in the UI sense it might not make sense in your application.

If you have any questions or comments please feel free to make them. I'll try to provide a more practical real world example of this in action soon.

Saturday, October 24, 2009

Starting Back Up Again

It has been a little while since I last found the time to blog. So here is me planning to start again. My goal to begin with will be to publish at least two blogs a month.

The main cause of my absence has been the I ended up switching jobs and found myself in a very different type of situation. No longer was I fixing computer problems, and therefore coming across interesting issues, the solutions to which would be of interest to readers.

My new job takes me back to the field of web development, and so far I'm happy with this. It certainly is helping me continue to improve the skills I started developing when I built Local Sing.

This shift in career focus will lead to a shift in blog focus. I will now try to post and further develop some of my code for the benefit of the community. My end goal is to begin a least a few interesting open source projects that may take on a life of their own.

Up next: A php, mysql database comparison script.

Wednesday, July 22, 2009

Calyx Point freezes at Credit Report (Vista)

Issue:
Ran into an issue a few times lately where Calyx Point fails to automatically insert liabilities when requesting a credit report. The symptom, essentially a freeze that takes a very long time to resolve, is caused by the Calyx Document Converter. It will resolve on it's own, however only once have I had the patience

Solution:
While Point is "frozen", open the printers folder. (Start | Control Panel | Printers) Double click the "Calyx Document Converter" to bring up the current batch of print jobs. Highlight and delete (via the "delete" key or right click to cancel) any print jobs that are there. Be patient. Once the jobs have been cleared out, Point will continue normally.

Notes:
This seems to only be an issue with Vista, and may come down to permissions. Setting Point to be run as an Administrator (right click point shortcut, properties | compatibility) may fix this issue as well, though I have not experimented with it to that end.

Tuesday, April 21, 2009

POST and GET are not two ways to do the same thing.

While the end result seems to be the same thing, the subtle differences are very important. POST should be used when you are sending data to the the server to be processed, saved, etc. GET should be used when requesting dynamic information from the server. In effect, GET tells the server what YOU want. POST tells the server what IT wants.

Why? Well, the short answer would be to say that web pages are RESTful services. You can read up on REST here. But that answer sucks. It can be tempting to always use POST because it keeps your URL pretty and clean without ?a=bunch&of=unreadble text. But perhaps the best reason to give as a concrete why, is the way browsers will handle the information. When you POST data, the browser assumes that you won't want to post it again. It will pop up a waring to the user asking something to the effect of "Do you want to submit this information again?"

If you follow the concept that POST is for submitting data such as: creating a user account, entering shipping information, logging in... you will find that this behavior from the browser is in line with your web application.

GET on the other hand sends it's information in the the URL string. While this can look a bit ugly. The pages work much like static pages, and this sort of behavior is much more appropriate when doing things like navigating search results (users may want to return to previous results) or loading articles or other task where you are GETting something.

So, try to keep in mind when choosing a form method, are you sending information to the server or are you asking for information.

Wednesday, April 1, 2009

Local Sing Launch

I love the internet on April Fools. Somebody always manages to trick me, another will make me laugh out loud, and still more will actually make me wish the joke was real. It is perhaps for the reason that I enjoy the numerous fake announcements and the odd tradition of it all that I have chosen today to release my first home grown idea to the world. No joke.

LocalSing.com is my baby, and so far I have been the only developer working on it. It is a website that brings together Karaoke DJs and Singers. DJs promote their karaoke nights and Singers can search for specific songs and find a mic local to them.

It is as most things on the web are made to be: a constantly evolving work. I have a number of must have features still in the works, but development has been rapid and I don't plan to slow down now. The site is complete in that it delivers on its core promise. I look forward to promoting the continuing improvements to the site here as well as connecting with some of my users.

If you get a chance, take a look! If you are a Karaoke DJ, please sign up and help me grow!

Labels: ,

Friday, March 27, 2009

The Key to Return Business: Don't Shut Out Your Buyers

I'm a bit obsessive with most things. I'll immerse myself in something, and ignore all else until I've had my fill. This is especially true of video games, and no other genre lends its self better to obsession than MMOs.

Recently I've felt the urge to go back to Final Fantasy XI, and was thrilled that despite their threats to delete account information after 3 months of inactivity, that they were offering what they call, the Return Home to Vana'diel campaign. This alluring concept got me excited, but eventually let me down.

The problem is that they require you either to have a still active PlayOnline account. Which still only services 2 games, FFXI and Tetramaster. Who on earth actually kept thier PlayOnline account active after quitting FFXI? Since I did not, I would need my original FFXI booklet with the registration code on the inside. Sorry, Sqeenix, but I lost that years ago.

I have to wonder how much money they are missing out on because they can't seem to see the value in what every other MMO seems to already know. If you leave your user's data alone, eventually a lot of them will spend more money with you.

I can't count the number of times I've let my World of Warcraft account expire only to play again a few months later. If there is a model for success worth trying to copy out there, it certainly is WoW.

It must be a slow month, this is my second post about a company that just doesn't seem to want my money in recent memory.

Thursday, March 26, 2009

OnLive, True Linux Gaming At Last?

OnLive just announced a very interesting service today that will run the latest video games on a powerful server, and feed you the video within milliseconds.

At first I was skeptical, which was followed by an odd wave of elitism as I hoped they would fail to bring performance hungry games to mild mannered machines. (I've always loved building and pushing computers to the limit, largely to play games) But then I settled down and realized the potential if what they claim to have developed is the real deal.

I quickly realized how the device could change trips home to Mom's where there isn't a gaming console in sight. I could just bring onlive along. It would bring the full breadth of gaming enjoyment to my linux desktop, with or without fussing with getting the 3D hardware working, windows emulation and bitter disappointment.

It opens up a lot of doors that I just can't wait to peek inside. It does also bring out some worrisome hypotheticals too. For instance, if every kid on the block is using a lot more bandwidth than before, what will happen to the speed of our cable internet? Can I play with multiple friends at my house on various devices without grinding any connection to a halt. Saving me $100-$200 a year in hardware upgrades, won't do me much good if it costs me $30 per month in extra internet costs. And what will the service it's self cost when it is availalable?

Still, the concept is a strong one. I'm thinking it may be an OnLive christmas this year.