Zend Framework vs. CodeIgniter
I hope nobody minds but this is going to be more of a rant than an actual performance comparison of the two frameworks. First of all I started using CodeIgniter almost two years ago, and while it was a bit of a thorn at first it was never super difficult to figure out how to do stuff. The documentation was easy to understand and full of examples of what to do, plus things worked when I did them. As a result I've used CodeIgniter on several projects since.
Recently at my current job the powers that be (hereafter referred to as "they") decided to go from a progressive coding approach to a more MVC type approach using a framework (either custom made or already built). I'd like to point out that I'm all for using a framework especially on the applications we've got right now. I did suggest CodeIgniter as the framework of choice but my suggestion was received with disgust, so I kept my mouth shut...big mistake.
After attempting to build their own MVC Framework "they" decided to go with Zend Server Community Edition. Now I didn't (and still don't, which is sad) know a lot about the Zend Framework so I was somewhat excited to see it in action, especially since my experience with CI has been so great. And I guess maybe that's one of the reasons I'm posting today.
For anyone out there wondering if Zend is a good match for you, STOP!
For anyone out there who recently implemented the Zend Framework, WHY? It's not to late to turn back.
I've been working with the Zend Framework for about two weeks now, and I don't expect to know everything there is to know about Zend but I do expect to know SOMETHING. Let's just take a trip down memory/nightmare lane.
Please excuse me if I can't remember all the details, I've tried so hard to block some of this from ever resurfacing.
My first task was to figure out how to ajax with zend, seems simple enough right? Shoot zend even created a helper that loads the (almost) latest jQuery libraries for you so you never have to worry about being up to date. Not only that but zend has a way to build your Ajax request so you don't have to know how to do that yourself either. What they don't tell you is that in order for the jquery libraries to be loaded on your page, you DO have to use at least one of their custom php jquery building tools (in other words, you can't make all your jquery by yourself), otherwise the libs just wont load. Instead they let you beat your head against your desk for hours and hours until you finally un-comment a test jquery builder you had previously used only to find out that was the missing piece.
Next our whole team has been tasked with creating a new application using zend, it's been over a week now, I still feel like I don't know anything. Now you might be saying to yourself, "did you try google dipstick?" Yup sure did, and as google does it pulled up all kinds of links. Almost always the top 5 go strait to the official zend documentation which is by far the worst documentation I've ever seen about anything. It's like when someone has a secret and they know you want to know, but they know that if they tell you then they'll lose the leverage they have on you, so they just hold on to it with that smirk on their face and never tell you anything. There's all kinds of words but they don't say much and the examples are horrific at best. One example I was looking at had a variable in it, and they'd conveniently cut out the part where they actually initialize that variable so you have no idea what values it is supposed to hold. Turns out it was an array, but I still don't know if it was a named array or if it can simply be numbered. I actually got a little excited when I stumbled onto the Programmers reference guide, I thought "yes if anything will help this is it", I was wrong to think that and I apologize.
Now here's the kicker, I do need to backtrack a bit. When you install zend there is a GUI that is installed to help you manage how the server works, I've recently lost this GUI, by lost I mean I know where it's supposed to be and the files are all there but the GUI doesn't show up when i put the correct URL in my browser. So I started researching this, only to find that a certain part of the server called lighttpd is not running, the GUI is the only thing that requires lighttpd. So i started googling lighttpd is not running and got a fair amount of hits on that one. None of which helped. Finally I decided to create an account with the zend forums and humbly ask the zend folks themselves what to do about my problem.
To my dismay, when I logged in I found a little counter at the bottom of the page that said "Users browsing this forum: disgruntled and 0 guests" (if you haven't guessed, I'm 'disgruntled'). You have got to be kidding me, I'm the only one on this forum? Now to be fair it was after 5:00 on the east coast so I imagine the 3 people using zend in that part of the world have gone home.
how many people on this forum?
Needless to say, I'm a little disappointed, awe who am I kidding? I'm downright furious.
On the flip side, if anyone reading this has any idea on where I can get my hands on some useful examples of zend at work. Please leave them in the comments.
Print This Post
IE phantom borders (aka the ‘mazda bug/fix’)
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.
Print This Post
IE6 and form submit fixery
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.
Print This Post
The economy tanked and Team Awesome was destroyed
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)
Print This Post
The joys of Try Catch (in a jsp)
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).
Print This Post