Looking for a place to anchor some content – easily accessible, but non-intrusive? I was recently looking for a way to make the “Reservations” tab for the restaurant site Rialto Cafe a little less in-your-face, but still easily accessible from anywhere on the site. Putting it in the header just seemed too cluttered, and the footer pushed it too far down the page.
Enter the ‘slideout tab’ – It’s nothing new, you’ve probably seen it before, mostly used as a “feedback” tab. But in this case, I used a little jQuery plugin called tabSlideOut. The jQuery has several parameters you can set, including size, speed of animation, and position on the screen. In this case, I was using WordPress and just pulled in a form using the WP get_template_part(); function. But you could just as easily code in your html, or use ajax to load in something dynamically.
What you end up with is a nifty little “drawer” style tab that you can slide out from a fixed or floating position on either side of the screen – and it’s cross-browser compatible.
So today I was getting an error when I ran syncdb on my new django app. So usually when I have a problem in my code I either put in a breakpoint using PyCharm (more often lately), or I put in a pdb.set_trace() statement at the appropriate line number. This however was not my code, so I did not want to modify it. I also could not use the breakpoint method above because it was on the server. So how to get there so I could examine the variables to determine what exactly was causing the sql error in my case. It turned out to be really simple use:
ipython --pdb --c="%run manage.py syncdb"
This resulted in a debug prompt upon the exception. Then I used the ipdb command “args” to print out the arguments to that function. Upon looking I determined that the name field of the auth_permission table was too short.
So when you record a video with your iPhone it does some special magic. For example if you hold the phone upside down and record the video the video will be of course be saved upside down, but it will also store the orientation of the phone when the video was made. Then when the user plays it back on an Apple device, it rotates the video because it assumes the user does not really want to see the video upside down. This would be all fine and dandy, except now if the user emails the video to a PC user when the PC user opens it the video will be played upside down.
What would I prefer? I would prefer that Apple rotates the video, and then store an attribute some where in the video file that the video was rotated from the original.
Why is this a pain for us? Well, we have users uploading videos to a web site, and now we are going to have to rotate the videos (either by ffmpeg or HTML5). So far my attempts have resulted in either very lousy video quality, or a huge file. The HTML5 solution would be create except this wants to rotate the controls. So I would have to separate the controls from the video, and video playback fall back for browsers that are not HTML5 compatible would probably still be upside down.
Perhaps those more seasoned than I in the ways of javascript already know this – but I just spent 2 hours trying to fix a javascript problem that ended up having a very easy solution. My google searches came up fruitless – partially because I was using search terms to describe symptoms that I thought were related to a completely different problem – but fruitless nonetheless.
Here’s the issue. I have a simple javascript form on a hotel website – you fill in your check-in date, check-out date, number of adults and number of children, and rather than process the data and actually search, the form just builds a simple URL string and passes it off to their main corporate site (in this case, Doubletree) to use their massive internal booking engine. Easy right? All I have to do is come up with a URL string, put together with variables from the form, in a function that runs with the onClick event on the submit button – the form never actually submits. Take that URL string, throw it into a window.location, and off we go. Elegant? Notsomuch. Effective? Youbetcha.
Here’s the javascript:
function res_form() {
var rdir = "http://secure.hilton.com/en/dt/res/choose_dates.jhtml?ctyhocn=DENCHDT&arrivalDay="+document.resform.arriveDate.value+"&arrivalMonth="
+document.resform.arriveMonth.value+"&arrivalYear="+document.resform.arriveYear.value+
"&departureDay="+document.resform.departDate.value+"&departureMonth="+
document.resform.departMonth.value+"&departureYear="+document.resform.departYear.value
+"&numAdults="+document.resform.HowManyAdults.value+"&numChildren="+
document.resform.HowManyChildren.value;
window.location = rdir;
};
Simple, right? Problem is, the adults field and the children field were not getting their values passed through. Well, that’s not accurate – Firefox/Safari/Chrome were putting the values for number of adults and children in the correct places – in other words, document.form.adults.value was coming out correctly. However, in IE – (oh, boy, here we go) – this was not happening. These values were empty, which pretty much killed the URL string and the Doubletree site didn’t know what to do with it and just threw a blank screen back at me.
After much consternation and googling and bad words rattling about in my head, I decided to pick apart the form itself, piece by piece, since most of this code was something I inherited from another firm. What I found was that while non-IE browsers will take the actual value in a field and store it as document.form.field.value, IE needs a more explicit kick in the teeth, and requires that the ‘value’ attribute in the HTML
So what I had was:
Firefox and Chrome likey, IE no likey. What I needed was:
Everyone’s happy.
A very simple HTML solution to what appeared to be a javascript problem. I was convinced that those form elements were getting pushed through as null or something – but they weren’t, they just didn’t have a valid explicit value set to them, so IE had nothing to assign to them, whereas Firefox took the intuitive step of actually taking the value within the
So there you go. Probably a “duh” moment… I’m ticked that it took me two hours to figure it out, but hopefully my little odyssey helps someone else.
The Mad Lab blog has sat here empty for many many moons. Paul and I were discussing the other day that we really need a place to start documenting some of the various things we run across during project development – errors we find, problems we solve, problems we don’t solve, things like that. And it struck me that this blog is perfect for just that. If it’s only an internal reference, that’s fine, but if we can help other people out, all the better.
So here you’ll find just random stuff that comes out of our workflow – probably nothing exciting, but hopefully something useful.
