Calendar
|
|
September '10 | |||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | ||
Quicksearch
Interesting Sites
Archives
Categories
Syndicate This Blog
Creative Commons
jQuery: Edit Content Inline on Dynamically Created Elements
Unless you've been living under a rock while learning jQuery, everyone should have learned of the .live() call within the jQuery JavaScript toolkit. If you haven't, shove that rock aside - the .live() method takes the place of bind() (which is the more powerful, and base method of .click(), .blur(), etc...) for elements that are created dynamically at runtime. If you dynamically create elements after the DOM has loaded, and assume generalized JavaScript functions you've written to target these new elements (we'll presume you're targeting a "findMe" class) will work. Well it won't, unless you use .live().
Now that we have that out of the way, another one of jQuery's really great features that mimics why Wordpress is so great - all of the user contributed plugins, whether they're efficient or not, the fact that someone else has already created a solution for you, and is willing to share it with you (most likely for free) is awesome. One such type of plugin that I was looking for today, and knew I'd want to eventually use at some point, was an edit-in-place, or inline edit plugin - something that allowed me to edit content from within the DOM, such as in a DIV container (not in a textbox - or at least not initially rendered in one) dynamically.
In my case today, I was experimenting with dynamically creating elements that might need to be edited after being created. My first gut-instinct thought? Yup, you guessed it: .live(). I replaced the call to .bind() in the plugin's source and voilà! Nothing. It didn't work. The jQuery code in the plugin had been optimized beyond a point where I was comfortable to modify it further and understand what I was doing in order to make it work (which was kind of pathetic, but I digress).
So, how could I solve my little problem? Quite easily - I wasn't really thinking.
The call to instantiate an event on targeted objects after the DOM is ready is something like this:
I was scratching my head, trying to figure out if I'd have to uninstantiate all elements and reinstantiate the event bubbling throughout the DOM each time I created a dynamically created element. I was over-thinking it. Instead, all I had to do was create the event on that newly created element on the element's creation itself. Ooh, hard. I know, I know - I'm brilliant!
jQuery v1.4+ example code:
Now that we have that out of the way, another one of jQuery's really great features that mimics why Wordpress is so great - all of the user contributed plugins, whether they're efficient or not, the fact that someone else has already created a solution for you, and is willing to share it with you (most likely for free) is awesome. One such type of plugin that I was looking for today, and knew I'd want to eventually use at some point, was an edit-in-place, or inline edit plugin - something that allowed me to edit content from within the DOM, such as in a DIV container (not in a textbox - or at least not initially rendered in one) dynamically.
In my case today, I was experimenting with dynamically creating elements that might need to be edited after being created. My first gut-instinct thought? Yup, you guessed it: .live(). I replaced the call to .bind() in the plugin's source and voilà! Nothing. It didn't work. The jQuery code in the plugin had been optimized beyond a point where I was comfortable to modify it further and understand what I was doing in order to make it work (which was kind of pathetic, but I digress).
So, how could I solve my little problem? Quite easily - I wasn't really thinking.
The call to instantiate an event on targeted objects after the DOM is ready is something like this:
I was scratching my head, trying to figure out if I'd have to uninstantiate all elements and reinstantiate the event bubbling throughout the DOM each time I created a dynamically created element. I was over-thinking it. Instead, all I had to do was create the event on that newly created element on the element's creation itself. Ooh, hard. I know, I know - I'm brilliant!
jQuery v1.4+ example code:
Adobe AIR 2.0
As I was redesigning the interface to my "RefStat" (Reference Statistics Tracking) application, I came across a web page that claimed support for CSS3 in Adobe AIR, so immediately began creating the new interface using Safari 4 as a testing ground for my UI. After almost completing it, it was brought to my attention that this would not be available until version 2 of AIR was released. I am still using v1.5.x. Not awesome.
The good news however, is that there is a public release of AIR 2.0 Beta 2 for download, which gives me hope that the stable release is not too far away. Since I am also waiting on an update to the tooltip library I am using, this wait hopefully won't be too long after I am ready for it.
New features in Adobe AIR 2.0 that I am looking forward to:
Features planned for my redesigned UI (v2):
I might add a graph rendering to display current stats for the day too as I've been asked for it, but it wasn't meant to view reports, only create the data used for them. This seems less important to me than the user interface and code updates though (template/skinning was so users could switch between horizontal and vertical displays depending on their desktop icon arrangements or resolution).
Current mockup (without tooltip) rendered by Safari 4.0.5 for Windows.

I never claimed to be a UI designer.
The handles on the left/right sides are "grip" or handle areas in order to move the application. The resize/change template button is not yet implemented in this template (though all controls would be in the orange group). The notepad is the new feedback button (in place of the "T|" from before), and of course minimize and close. The image shows a hover state, not a mouse-down state. The colors are meant to be similar to our library's "official" color (#621E27 or close variations).
The good news however, is that there is a public release of AIR 2.0 Beta 2 for download, which gives me hope that the stable release is not too far away. Since I am also waiting on an update to the tooltip library I am using, this wait hopefully won't be too long after I am ready for it.
New features in Adobe AIR 2.0 that I am looking forward to:
- UDP packet support (interfacing with some game servers)
- TCP/open socket listening (acts as server)
- ~30% more efficient than AIR 1.x
- WebKit version updated to Safari 4.0.3 equivalent
- (Better?) Printer support
Features planned for my redesigned UI (v2):
- 8+ more buttons? 800x600 or less resolution? No problem anymore! The buttons wrap and the app scales.
- Templates/Skinning support
- No more color coded buttons (in default templates)
- Redone UI in my template won't have the hover bug for tooltips (mouseout from inside AIR app, thinks you're still hovering)...AIR 2.0 might fix this on its own.
- On-the-fly template switching
- Refactored object class
I might add a graph rendering to display current stats for the day too as I've been asked for it, but it wasn't meant to view reports, only create the data used for them. This seems less important to me than the user interface and code updates though (template/skinning was so users could switch between horizontal and vertical displays depending on their desktop icon arrangements or resolution).
Current mockup (without tooltip) rendered by Safari 4.0.5 for Windows.

Reference Statistics Tracker for SSPL v2
I never claimed to be a UI designer.
Website Render Time with PHP >= 5.1
In CakePHP v1.3.x, there will no longer be an automatic dump of tons of information (probably because the DebugKit plugin can handle all of that information for us) when in debug mode. However, in my non-CakePHP websites, and even in my Cake websites, I have become accustomed to viewing the source to see a full render time for the page in an HTML comment. Thanks to the help of "jnay" over at CakeQs.org, I've found out about a new (as of PHP 5.1) $_SERVER variable argument called "REQUEST_TIME". It holds the UNIX timestamp of the initiation of the call.
By using this variable, along with the optional boolean argument for microtime (as of PHP 5.0.0), we can determine the HTML render time of our application with the following calculation in either our footer view/template, or controller (preferably in the last possible iteration of your project's render):
The echo is optional and used only as an example here; it simply depends on how you use the calculation in your script(s)/framework(s). This is much easier than starting the timer in the header and calculating the difference in the footer like I had to do in the PHP 4 days!
Remember, this is only for trivial estimations and comparisons. If you need to thoroughly evaluate your script(s) for time efficiency you should be using something else, such as Xdebug and a form of CacheGrind for your choice of OS.
By using this variable, along with the optional boolean argument for microtime (as of PHP 5.0.0), we can determine the HTML render time of our application with the following calculation in either our footer view/template, or controller (preferably in the last possible iteration of your project's render):
The echo is optional and used only as an example here; it simply depends on how you use the calculation in your script(s)/framework(s). This is much easier than starting the timer in the header and calculating the difference in the footer like I had to do in the PHP 4 days!
Remember, this is only for trivial estimations and comparisons. If you need to thoroughly evaluate your script(s) for time efficiency you should be using something else, such as Xdebug and a form of CacheGrind for your choice of OS.
Cassie Print Station - Automatically Close the Window
Cassie is a PC Reservation Management system software built for libraries, or other venues that wish to offer multiple PCs for the public to use. It also has a print management station. Unfortunately, as of the current version, when a user goes to view their own print jobs, their account window stays active "forever" until they, or someone else clicks on the "Close" button. When using with a JAMEX corporation coinbox, it also doesn't give the user their change until the window is closed (insert $1.00 for a $0.60 charge, it won't expell the $0.40 until the window is closed).
This is a bit of a problem.
I've used AutoIT, an automation scripting language, to automate the process of a user clicking on the close button. The makers of Cassie didn't make it easy though, I was unable to detect the actual button, thankfully ALT+F4 worked (ESC worked until the JAMEX portion was added, for some reason it stopped working afterward).
This uses the included Timers.au3 file to do most of the dirty work in detecting an idle state. If the computer is left idle for 45 seconds, it will issue ALT+F4 and close the window. ALT+F4 cannot close the application itself in this instance (and won't be issued unless that window exists and is active anyway). Although it checks every 100 milliseconds and runs at all times that the computer is turned on, I tested the resources it takes up...it was barely noticeable on an old P4 @ 2.80 GHz w/2.86 GB RAM (my work PC). This application (once compiled with AutoIT) should be placed in the Windows' Startup folder (or a respective registry key).
This is a bit of a problem.
I've used AutoIT, an automation scripting language, to automate the process of a user clicking on the close button. The makers of Cassie didn't make it easy though, I was unable to detect the actual button, thankfully ALT+F4 worked (ESC worked until the JAMEX portion was added, for some reason it stopped working afterward).
This uses the included Timers.au3 file to do most of the dirty work in detecting an idle state. If the computer is left idle for 45 seconds, it will issue ALT+F4 and close the window. ALT+F4 cannot close the application itself in this instance (and won't be issued unless that window exists and is active anyway). Although it checks every 100 milliseconds and runs at all times that the computer is turned on, I tested the resources it takes up...it was barely noticeable on an old P4 @ 2.80 GHz w/2.86 GB RAM (my work PC). This application (once compiled with AutoIT) should be placed in the Windows' Startup folder (or a respective registry key).
Server Load, Take 2
So I worked on the CakePHP plugin for Prowl a bit more, and in doing so, I created shell-based access to the plugin. I can now send Prowl messages from the console (i.e.: I can run PHP via cron to check on things and send myself the results, if necessary). A shell task I created was for server load, as a followup to my previous post. In working this out, I've modified the output for CakePHP's Shell::out() method so that it auto-wraps and indents a bit more nicely (my ticket in the LighthouseApp is here). Time for some output examples:
Issuing the Load Alert help call: cake prowl load_alert help
Sending a message is as simple as: cake prowl msg [apikey] ... it can get as advanced as cake prowl msg [apikey] [priority] [application] [event] [description]
The output for running the load alert command?
If it's above my arbitrarily set values, it'll send a different warning depending on the level to my Prowl-enabled device. By sending a "-silent 1" parameter to the command message, output is disabled (perfect for cron).
Please note that I don't have any styling for shell output (something I'll have to fix) so the pasted character spacing and newlines won't work as expected in my example output.
Issuing the Load Alert help call: cake prowl load_alert help
Sending a message is as simple as: cake prowl msg [apikey] ... it can get as advanced as cake prowl msg [apikey] [priority] [application] [event] [description]
The output for running the load alert command?
If it's above my arbitrarily set values, it'll send a different warning depending on the level to my Prowl-enabled device. By sending a "-silent 1" parameter to the command message, output is disabled (perfect for cron).
Please note that I don't have any styling for shell output (something I'll have to fix) so the pasted character spacing and newlines won't work as expected in my example output.
(Page 1 of 8, totaling 39 entries)
» next page
2010 mysiteonline™ | entries (RSS) | Comments (RSS) | Theme xcur

