Posted by Phil on March 17, 2009 under Web Development | 
I believe every web developer has probably had to deal with this at one time or another. It all starts out with a beautiful layout and a few floats, you check the design in FireFox, then in Safari, you open Chrome, and finally you even test in Opera. Everything looks fantastic, you are all smiles and blue skies…
Firefox3 No Border Problems
But there’s a problem, lurking beneath the genius of your layout is a CSS border on one of the div’s, and inside that bordered div is a floated object/element. Normally with modern/compliant browsers, this isn’t an issue, but IE is neither modern nor compliant by any means. So you crack open IE7 (the lesser of current evils) and notice that your border seems to ‘disappear’. More weirdness, you scroll around the page and the borders re-appear (similar to the peek-a-boo bug, but no this is different).
IE7 with Phantom borders
So you crack open your VM (cos by now you’d better only have ie6 in a VM – or using xenocodes ie6.exe… unless you have office 2k7 installed, at which point your existing installation of ie7 may go suicidal on you – another story for another post) and you check to see how ie6 renders the page.
It looks like IE6 broke your internets
Wow, you can’t see it (because I cropped the image), but the entire layout of the page has exploded, I fixed it originally with extra css, but before I did, I had div’s coming out of the containing-div, odd margins, and the container has gained 20px on the right. Oh, and the borders are still disappearing and reappearing on me.
So what are you supposed to do when this happens? Well first I tried changing the flow of the page, taking out the float and lining things up with out it. I already had a separate ie6 and ie7 style-sheet, so it was almost working. I say almost because I really did need to float an image and no matter how I changed the presentation (CSS) I could not get it to line up AND have the borders appear normally. This is when I stumbled onto the greatest IE discovery since dd_belatedPNGfix:
#reviews-all-box {
zoom: 1;
} |
Yep, that’s it, “zoom: 1;” -hence the term ‘mazda’, get it?- on your div that has the border. This forces IE to turn on the IE only ‘hasLayout’ tag which then changes the way the page is drawn in IE. Yes, there is a lot more to it than that (read here), but the quickest way to enable ‘hasLayout’ is to just throw zoom in your css. After using the above code on my ie6 and ie7 style-sheets the problems went away, both IE versions have magically obeyed CSS formatting, and the borders are where they are supposed to be (without disappearing).
This is IE7 with zoom: 1 (yes IE6 looks the same)
So what have we learned? M$ is in league with the auto industry (think of SYNC…!). No I’m just messing with you, what we learned is that if you decide to make a browser, please for the love of the internet, please, please, I beg of you, please, make it W3C standards compliant so that we don’t have to keep using these ghetto hacks to make it act like it should.
Posted by Phil on January 7, 2009 under Javascript, Web Development |
Yesterday presented a problem I was unfamiliar with, and while ie6 continues to be the bain of all web developers existance, I finally was able to emerge triumphant, with the head of the demon tucked nicely under my arm… for now. The problem of course is trying to submit a form through javascript with ie6.
After poking around the large interweb I stumbled on another site that had run into the same problem. a slightly more indepth description of the problem is that you have a form, but rather than use a submit button, you have an image wrapped in an a-tag that you have assigned a click-event too that submits the form (or sends it to some js validation, and then submits the form). This is all fine-and-dandy with any ‘modern’ web browser, but for some reason that only m$ can tell us, when ie6 follows the a-tag, it gets lost without ever submitting the form, it doesn’t even attempt to load the page.
Some people have reported that adding an empty anchor to your a-tag fixes the problem (you know, a simple >a href=’#'<), but we like code that validates, so we usually insert ye olde ‘javascript:void(null);’ into our a-tags when we handle them with onclicks, or jQuerify them.
The solution that we ended up using was to use a setTimeout(); around the form submit in the js. For some reason, this allows ie6 to remember what it was supposed to do and get it done. I like to think of it as a virtual kick in the teeth to the browser. Anyway, here is some sample code to help you visualize the problem and solution.
Here is our form, (yes, it has a smattering of JSTL in it 
, you can ignore that if it bothers you)
<div class="review-form-input">
<a href="javascript:document.reviewForm.submit();">
<img src="<c:out value="${jspStoreImgDir}" />en_US/submit.gif" alt="Submit" />
</a>
</div> |
And here is our sample javascript code BEFORE being fixed (note the jQuery goodness, that I can’t use enough of)
$(document).ready(function(){
$(".submit a").click(function(){
$("#reportForm").submit();
});
}); |
Note that the above code works fine in Opera 9+, Safari 3+, Firefox 3+ (and most-likey but untested in Firefox 2+), and yes even the black-sheep of the browser family ie7 can render and run this code just fine.
Here is the fixed javascript…
$(document).ready(function(){
$(".submit a").click(function(){
setTimeout('$("#reportForm").submit();', 50);
});
}); |
Yep, that’s it, a very subtle change, just inserting the setTimeout() method fixes the ie6 stupidity.
Posted by Phil on December 9, 2008 under Off-Topic |
Yesterday we recieved shocking, horrible, soul-destroying news. Team Awesome would be broken apart and fed to the wolves. I am sure this was not an easy decision, and the hours of sleep that were (and are) missed are but a small tribute to the pain that our department now feels. Our company decided that we all needed to cut spending, so four people from our department were shown the hatch. Of the four, we lost Dustin and Ninja effectivly cutting Team Awesome in half. Two others were thrown into the fray, Branden from Ryan’s Team, and Ben… our ‘one man island party planning genius with flair’ (although our customer service dept hired him as an email tech).
We recieved more company emails and heard stories from the other departments (the other MIS team lost 6 people), but some of us are still here, it’s just colder and lonelier.
Anyway, here’s to Dustin,Ninja, Branden, and Ben. May some karma kick in and get you guys something nice (sound of a lid opening), here’s one for me (swig), and four for my homies…
(As a side note, I hope that Dustin, Ninja, Ben, and Branden will continue to post here, because you guys will always be welcome here)
Posted by Phil on April 7, 2008 under Websphere Commerce |
This post is brought about after having Ninja come over and look at my code and making me realize that while what I was doing was good, I had not used a try catch and as such would never find exactly why my code was generating over 1500 lines of errors in my server log (ouch). Here is the way of Scriptlet (aka ninjascript) Try Catch-ery.
<% try { %>;
<%-- code goes here --%>;
<% } catch (Exception e) {
e.printStackTrace();
Thread.sleep(20000);
} %>; |
You can further mod this to make it possibly more helpful by adding/replacing the last line so you end up with something like:
<% try { %>
<%-- Code goes here --%>
<% } catch (Exception e) {
System.out.println("Exception caught in NameOf.jsp");
System.out.println(e.toString());
e.printStackTrace();
} %> |
Now for those people who are purists and understand that scriptlets really are not up to par, and that they are ugly and screw things up and are not elegant in the least, there is another way to Try Catch on your JSP. Simply use a JSTL Try Catch. Here I’ll set up an example:
<c:catch var ="catchException">
<wcbase:useBean id="category" classname="com.ibm.commerce.catalog.beans.CategoryDataBean" >
<c:set value="${WCParam.parent_category_rn}" target="${category}" property="categoryId" />
</wcbase:useBean>
</c:catch>
<c:if test = "${catchException!=null}">
The exception is : ${catchException}<br /><br/>
There is an exception: ${catchException.message}<br/>
</c:if> |
We set up a variable (catchException) and then what we want to do inside that c:catch. So we are trying to instantiate this bean and we want to make sure it doesn’t throw an error (which as part of the joys of websphere if that bean throws an error your page will fail and you’ll either get a portion of your page with nothing else, or you’ll get a series of dreaded CMNxxxx errors). Right after the c:catch block we set up a c:if with to test value of ${catchException, if it’s not empty, then an error was thrown and we should kick out what the error is so that we can fix it (without digging through 1500 lines of error-logged code).
Tags: catch, cmn, debug, error, help, jsp, JSTL, try, try/catch, websphere sucks, why me
