By mike@mike-miles.com
I had a bit of free time over the last week, so I thought I would try my hand at creating a jQuery plugin.
I call it jQuery.fly
What it does is allows you to create some cool animation effects to any text elements on the page, it also has a few built in effect. Useful? not really, but maybe someone will like it.
Some of the built-in effects are:
- bubbles : makes blue bubbles rise from the bottom of the screen
- blizzard: makes it snow on the page
- explosion: creates an explosion on the page
- fire: produces an ASCII fire on the page
Like I said, it’s supposed to be used for text effects, so you could make all the paragraphs on your page randomly move around when a page is loaded.
you can view an example here.
I’ve posted a more in depth description and download links on my projects page, jQuery Fly.
By mike@mike-miles.com
In case you don’t know (or didnt realize) web languages (like php, javascript, ect…) have evolved a long way from their first verisons (duh, mike). With that eveloution they have developed into languages just as complex as standard application languages (java, c++, ect). With the complexity comes the wonderful availability for OOP programming.
The thing is most web programmers are not OOP programmers, the standard for the web has been to be a functional programmer (just writing functions) so a straight up web developer might not be very familiar with OOP programming. OOP programming (creating objects and classes) can be a great resource when writing complex applications. This post is not about how to create an OOP web application (though, writing one might be handy). I wanted to write a post that describes my thought process of when to be OOP, because there are times when it’ll benefit you as a developer and times when it’s just unnecessary overhead.
Rule of thumb – functions
Now we all know that functions are a nessecity, reduces redundent code, automates things, makes your life easier (Side note: I had a few friends in one CS course during college who went the whole semester never writing functions just straight up code. The class was a bioinformatics course using perl so I have no idea why they wanted to do this.) I have a general rule of thumb before writing a function. For me to place code into a function it’s got to meet at least one of these requirments;
- Will I end up writing this code more then twice
- Is this code going to be utterly complex, and long (will break into multiple functions)
- Can I use this anywhere else
If the code matches one of those then I’ll put it into a function. If not I might even still put it in a function. The key is reusability.
Rule of thumb – classes/objects
Now my rule of thumb for creating a class and doing some OOP is almost like my rule of thumb for creating functions, except it deals with functions not just code;
- Will I need to reuse these functions multiple times? (and together)
- Would it benefit to prevent user from accessing these functions (using OOP ‘private’)
- Could I use these functions together in the future
So if a group of functions meets any of those requirements, I’ll rewrite them to be a class. For example, in PHP I have a general Email class that I can put into any project that needs e-mail capabilities. and to use it I just need to include it and invoke the object.
It makes it simple for me to add e-mail to any project, and reduces the code I would have to rewrite. This increases my time for further development.
OOP in web development is also a great plus because you can keep classes and objects independent from each project, allowing you to build up a library that you can use in any project (again reusability!). this reduces the time you have to take to rebuild something you’ve done in a previous project and gives you more time to produce richer, fuller web applications.
By mike@mike-miles.com
Gone are the days where you have to write extensive, ugly javascript code to manipulate page elements and DOM. Thanks to the development of some really great javascript frameworks you can do more with less (that sounds like a line out of a Walmart commercial). The big three libraries are jQuery, Prototype (with or with-out script.tac.ulous) and mooTools. Each has its advantages and disadvantages (A major disadvantage to all three is that it’s very difficult to work with more than one at a time). Just like shopping for a new car or deli sandwich, how do you know which one is right for you?
The debate on which javascript framework to use is an even bigger then the DIV vs TABLE debate (another article for another time), and plenty of opinions have been voiced. For example, Glenn Vanderburg who runs the blog Relevance recently wrote an article (on my birthday no less) about how he prefers Prototype over jQuery.
jQuery is a very nice piece of work, and makes some common tasks easier than their Prototype equivalents. Where it’s good, it’s very good indeed. But its design is uneven, and its scope is limited. For me, at least, Prototype is still the tool of choice. I think it’s a richer, more thorough, and overall better designed library.
In his artcle (I’m not going to post the whole thing, that would be plagerism) he explains many great points for both jQuery and Prototype, along with code examples to show his opinion;
So while jQuery might be easier to get started with, Prototype grows with you better. Most web developers get started with JavaScript by doing relatively simple DOM manipulation, and jQuery really excels there. But as you get more comfortable and begin trying to do more, you may find that jQuery doesn’t help you as much. Prototype makes JavaScript programming lots of fun even in circumstances where jQuery feels constraining.
Basically he explains that jQuery is nice framework, its more for programmers who are beginner / intemediate DOM manipulators, and Prototype is for more hardcore stuff. An opinion that I can agree with having both used jQuery and Prototype in projects. For example, in my senior year of College I was part of a development team and we were building a Project Management System. We had disxcussed that we wanted it to be ajax based, and as the lead developer/programmer it was my duty to make it function smoothly. At the time I had barely any experience with major DOM manipulation except for straight up javasript. The Team leader opened me up to jQuery, which I was able to pickup fairly quickly and easily.
In another blog by Trent Richardson (trents blog) he compares jQuery and MooTools ;
Mootools has previously been known for its silky smooth effects and great dom utilities, but they also have performance on their side as well. jQuery on the other had has to have the friendliest syntax ever with chaining and selectors, with just enough effects to make you hungry for more.
MooTools does in fact have the best preformance out of the bunch, Peter Velichkov over at his blog did alot of speedtesting for each of the major frameworks (it originally inspired me to write this article) which showed across the bored mootools was the fastest preformer.
So which framework is the best?
The true answer (which you’ll probably hate) is there isnt a best one. It’s all based on circumstance, for example if you wanted something lightweight and easy to use I’d go with jQuery. If you wanted something robust and powerful I’d go with Prototype, or if you wanted something really fast I’d pick MooTools.
Another factor is ease of use. You have to figure out which is best for you depending on your programming level. jQuery (easy), Prototype (intermediate/hard), MooTools (intermediate/hard). The more comfortable you feel with the tools your using, the overall better product you’ll produce.
I personally, prefere to use jQuery simpley for its ease of use. I can write powerful javascript functions very simply and fast alowing me to get more done in a shorter amount of time.
By mike@mike-miles.com
Recently for a project I needed to build a custom photo gallery web application, which would allow the administrators and site users to both uploaded photos. The thing about file uploads is that to the user (which in my case was administrators and site visitors) is that it can be very boring to the user, and not very elegant. Since users were providing additional information to the photo, I was saving everything to a database including the filename of the photo uploaded (for each upload I would generate a random name). I wanted the user to be able to upload their photo, preview it, then finish completing the rest of the form. Normally to do this would require at least 3 steps;
- Have the user upload their file, and submit the page.
- Reload the page, save the file then display a second form for the user to provide details
- save the details to the database.
Now this fine, a tried and true way to do it, but boring to the user because before they can finish filling out the form they would have to wait for the file upload to finish (which could take awhile depending on file size and connection). We dont want the user to have to sit there for a long time waiting for the upload to complete (idle users are BAD, for a number of reasons, example it gives them time to say ’screw it’ and navigate away from our site). It would be much better if the user had something to do while their photo was uploading, keeping them busy and happy.
So what I wanted to do was have the user select a photo, which would then (using AJAX) be sent to another page to upload, and return the file name. While this was happening the user would see a loading icon, and be able to complete the rest of the form. Once the upload page returned the filename, I would display the form’s submit button.
At first I was stuck on how to exactly accomplish this effect (I knew I wanted to use AJAX). After doing some googling I came across this solution.
Basically a full blown AJAX file upload is not possible, but we can get the feel and effect using a hidden Iframe.
Sorry to say I’ve had to remove this code for legal reasons.
but feel free to checkout the source I used to create the code to draft your own solution.