Hello. I am a web fixer.I solve problems on the web.
I’ve been in need of a basic button style for prototyping purposes lately, so instead of creating them over and over I just came up with a basic grey button created in pure CSS that I could use as a placeholder. I also used the :nth-child selector to change the hover color, but that’s just for fun.
My default button style
R.I.P. <time> element. The html5 semantic “time” element has been killed in the specification and replaced with the incredibly vague “data” element. Of course there is plenty of controversy surrounding this, but basically people in favor of the data tag say it can do more than the simple time tag. Unfortunately the time tag has been in use in projects like WordPress, Drupal and Google search results. It’s a shame.
Raphaël is a javascript library that helps in manipulating vector graphics on the web. Its some weird mishmash of SVG and VML, but I was able to produce SVG graphics in Illustrator that were fully compatible. I guess I take that back. The graphics were compatible, but the interactivity wasn’t. Illustrator has a basic interactions palette for SVG actions, but those didn’t import correctly so I had to leave them out and do all my actions in the framework itself. To create an object in Raphael using graphics you made in Illustrator, you need to use the save for web option and select SVG. Scalable Vector Graphics files look just like XML when you open them in a text editor, so its easy to copy and paste chunks of data.
If you want to see the paths, you can check out the javascript here. Basically all you do is create the Raphael object, then copy the paths out from your Illustrator SVG file and paste them as Raphael paths.
This graphic was originally created to provide users with graphic menu involving the regions of Texas
I’m not going to go into all the reasons why, but I needed a development server for my Drupal site. Setting up a local testing environment is very simple using XAMPP and MAMP, but the Acquia Dev Desktop claims to be the simplest way to get a local Drupal setup up and running. By now I’ve tested all three with Drupal, and I’ll try to outline the pros and cons as I see them. Keep Reading…
I’ve created a sample html5 form using every element I could find at Dive Into HTML5. Opera seemed to recognize the most elements by far, but the UI looks really really bad out of the box. The elements I tested were…
Screenshot of Opera's HTML5 form elements
Recently I had found myself with a good reason to save user data from a php form to a spreadsheet. (The good reason was somebody asked me to do it) The two best options I came across were…
The second option required more effort up front, since I had never heard of the Spreadsheet API before, but it seemed like the simplest solution for the client. You need to download the “gdata” files from the zend library, because google doesn’t host the php files for some reason. Once you have those you are pretty much all set. The documentation isn’t super elaborate on zend, I actually found more detailed info back on googles site.
One advantage of using this instead of a database is everybody knows how to use a spreadsheet. The client can simply log into google docs and view the data anytime without messing around with database scripts. I think that long term benefit is worth taking the extra time up front to figure out the API. Another cool bonus is that you can use Google’s authentication system if you want to control access.
I was noticing strange behavior on my dynamic form fields, which looking back seems obvious, but at the time I was preoccupied and couldn’t figure it out. I had some jQuery code running every time the user made changes to an input field. This all worked great. The problem was I had an “add more” button to create additional blank input fields on the fly. With each new field, the code that was supposed to work on the .change() event didn’t. Everything seemed right, it just plain didn’t work.
What I wasn’t thinking about was jQuery goes through my code, in this case on $(document).ready(), and matches up events and actions. When the user does this, JavaScript does this, and so on. It does not do this for elements that do not exist at that time. These dynamic input fields didn’t exist when jQuery was doing its thing, so they get no code applied to them. This is what I was using for the .change() event…
jQuery('.routeInput-title').change(function(){
var idNum = jQuery(this).parents('.routePoint').attr('id').replace('rp', '');
routePts[idNum].title = jQuery(this).val();
setJSON();
});
So this only applied to elements with the “.routeInput-title” class that exist when jQuery ran, and new elements created after this point are ignored. Fortunately, jQuery also has this handy .live() method, which applies to all elements created “now and in the future.” So all I need to do was change my code to this…
jQuery('.routeInput-title').live('change', function(){
var idNum = jQuery(this).parents('.routePoint').attr('id').replace('rp', '');
routePts[idNum].title = jQuery(this).val();
setJSON();
});
Now everything works as it should.
JQuery: .live()
Note: The code above uses “jQuery” instead of “$” because its for Drupal, and Drupal demands it.
If you are using JavaScript with your form widgets in Drupal, I thought the obvious place to attach the code was on hook_field_widget_form() using drupal_add_js(), but this causes problems if you allow for multiple values. Drupal runs hook_field_widget_form() for every instance of the widget, which totally makes sense, I just didn’t think of it at the time. I think the smarter place to put it is inside the form_alter hook, since that’s only run once. It’s run once for EVERY form on your drupal site though. Since I only had this specific widget running on the “route” content type form, I was able to specify the form id and modify the hook to only run on that particular form.
With all the unread pages piling up in my rss reader these days, I have been looking for a more efficient way to organize information. I have been using Diigo a lot these days and it’s working pretty well so far. You can bookmark and tag pages, but you can also highlight passages, add sticky notes and save pages for offline viewing later.
I’m using Drupal to build a travel site, and I just finished what I thought was the basic structure for adding destination content. I added all the fields and made sure functionality made sense, but I failed to notice the larger issue. This works for the first destination but what happens when somebody visits that spot and tries to enter the info a second time? or a third? or fifty third? Of course one person shouldn’t be able to claim that spot as finished and other travelers will have to write about destinations elsewhere, but with really popular spots you could have lots of redundant information.
On one hand, I don’t know that I care about redundant information that much. Everybody wants to be able to write about their own experiences, and those experiences could very well be quite similar to one another. Most comments on web pages are pretty similar and that never stops anybody. We want to put our stamp on it, even if it is unoriginal.
On the other hand, what about the user who might actually want to read this stuff? I have to assume such a person exists. The poor soul who wants some info about the Grand Canyon will find lots of similar posts and it could get very hard to sort the good info out of the sea of probably boring redundant info. I don’t like putting everything in chronological order, because that’s what I didn’t like about forums-sifting through paths of boring posts just to find the good bits. The one good aspect of it was they were tied together. Drupal has something called “Books” that sounds like it does something similar. http://drupal.org/documentation/modules/book
I do like voting to a point. It seems like voting has limitations too. You have to find all the content, good and bad to be able to vote on it. Yes it’s possible this project is too big for me, but that’s what I like about building stuff like this for myself. I get to tackle weird creative problems like this that wouldn’t otherwise come up in my day-to-day routine.
This site will always be a work in progress. These pages are where I muse and experiment with web technology, and I've long since given up on the possibility that I'm ever going to be "finished". The learning process as a front-end developer is unending.