Because sometimes I'm just fucking right...

Category: Coding

Software development stuff

Damn fucking blank screen

I should have something to say.  I do have something to say.  But it’s not coming to mind.  Maybe it’s the lack of sleep lately.  Well, if the term lately can encompass the past 25 years.  Maybe it’s the alcohol this evening fuzzing my brain.  There’s just not a whole lot tumbling around up there except a nice fog.  Maybe it’s the Godsmack playing on the Echo.  I’m not sure but my head just wants to nod with the beat and sing along.  But nothing fills my mind.  It’s blank.  Nothing to spew forth. No hatred, no anger, no diatribes of indignation at the world.  My spitfire is turned to lukewarm drool.  How’s that for a visual?

Ok, how’s this?  Strongly vs loosely typed languages?  Which do you prefer?  In my younger days I was filled with the conviction that the only true languages were strongly typed ones, like C, C++, and Java.  Damn it, if it’s a number, what kind? Is that integer signed or unsigned?  It fucking matters!  Why would you want to store a string in the same variable type as a double or a float?  Sheer lunacy!!! I had my reasons.  I was 100% confident in my convictions truthiness.  20+ years and a plethora of languages later, I realize it just doesn’t matter so much to me anymore.  In fact, now I find strongly typed languages annoying.  I mean, I still know how to use them. I know how to cast and such but it’s just a pain.  Give me a loosely typed language any day of the week.  Granted, I’d still rather use Java or C++ or even C over something like Ruby or Node but I’ll definitely pick PHP or even Python over a strongly typed language.  Maybe I’m just lazy in my old age? Nah, I’ve been lazy my whole life…

Zend Framework Documentation

So, I LOVE the Zend Framework.  I love it so much, in fact, that I’m a ZendFramework Zend Certified Engineer.   However, I have one rather large gripe about ZF and that’s its documentation.  At first glance, and even when you first start using it, the documentation seems rather good.  It covers lots of salient points and always gives you the quick and dirty way to get started.  The problem with it is that while the breadth of the documentation is very wide, it isn’t deep at all.  Simply put, the documentation is good if you’re doing simple things.  If you want to do anything complex at all, it’s fairly useless.  There’s a pattern I find myself following whenever I delve into a piece of ZF that I haven’t used before.

  1. Check out the ZF Documentation.  See if it answers all your questions
  2. Do a search on Google to see if anyone else has used the component you’re wanting to use in the fashion you want to use it
  3. Check out the ZF Reference API
  4. Crack open the ZF source code

Generally speaking, if you’re willing to spend the time to follow these four steps, you can figure out what you want to do.  The biggest problem with this is that sometimes after investing the time you realize that the coponent you’re researching doesn’t do quite what you want.  Frustrating!

Now, my wife always says you shouldn’t complain about something unless you have a solution to offer or are at least willing to help with the problem.  So, my solution is to write better documentation!  OK, that’s a no brainer.  I think the biggest frustration I have with the documentation as it stands is that there seems to be pieces missing when you’re reading it.  For instance, if I want to write a Plugin for the MVC components, there’s documentation that kind of outlines how to do it, but not really.  You really have to dig to figure it.  Now I know that sometimes digging through source code and trial and error coding is a great way to learn stuff but sometimes I just want to take a peek at the documentation and say “Oh! That’s easy!”

Here’s the kicker.  ZF is a very well designed.  Generally speaking, it will do what you want it to do.  It’s just the figuring it out part that is the issue.  And yes, all you trolls and haters out there, I use the documentation on an almost daily basis.  I recognize that what is currently there is good.  I even recognize that for a free product it’s even better.  Having said that, you need to acknowledge that a for profit company is tooting it’s own horn over ZF.  They have a team of paid developers working on ZF as their full time jobs.  I think that they also need to apply that method to their documentation for ZF.  It’s the logical next step to making a great framework even better.

Javascript Magic w/Optgroups

A good 8 years ago or so, a co-worker of mine and I worked out how to use javascript with select objects to create a “to and from control” like you’d see in Outlook for selecting to, cc and bcc from your address book. Essentially we setup 2 selects with arrows in between. We populated to the two and then used javascript to move the options back and forth between the two. It’s a fairly straight forward process and the javascript is pretty simple once you strip it down. Since then I’ve always wanted to figure out how to do a to and from control using optgroups but have never taken the time to do so. Well, a recent project at work finally gave me the excuse to figure it out.

The requirements for this control were pretty straight forward. First, it must function in IE6, IE7 and Firefox. It should work by moving an option from one select to the other, while keeping the option within its defined optgroup. For instance, if Kansas is in the optgroup Midwest, when Kansas is moved to the other select, it needs to go in the Midwest optgroup. If the Midwest optgroup doesn’t exist then the optgroup needs to be created first. I also toyed with the idea of removing the optgroups once they were empty. I got it working but there are some odd idiosyncrasies to the way the hasChildNodes function works so I’m most likely not going to include it in my project. The final, and perhaps most important requirement, is that the tool needs to keep track of what items are added and removed from the right-hand side select. So, how do we do this?

To start, we pass in the ids of the three controls. The to select, the from select and the hidden that will be storing our values. Assuming they load appropriately, we should be good to go.

var DELETE_OPTGROUPS = false;

function optgroupMove(toID, fromID, addID)
{
  var to = document.getElementById(toID);
  var from = document.getElementById(fromID);
  var deletedOptions = new Array();
  var hidden = document.getElementById(addID);
  var index=0;

Next, we cycle over the from select. Any option that is currently selected will be moved to the “to” select. To do this, we retrieve the selected option, get its optgroup, create a new option, add it to the select and then assign the text and value to it. It may seem odd to do the text/value assign last but it was the only way to get the appendChild function to work in IE.

for(x=0; x<from.options.length; x++)
{
  if(from.options[x].selected == true)
  {
    /* Create the option, add to select and then add text and value.
     * We do this because IE6 and IE7 lose the text and value when
     * added to the select after the text and values have been set.
     */
    var option = from.options[x];
    var optgroup = option.parentNode;
    var optgroupMove = document.getElementById(toID + optgroup.label);
    var newOption = new Option();
    to.appendChild(newOption);
    newOption.text = option.text;
    newOption.value = option.value;

So far, we’ve just stuck the option in the select. It’s not associated with an optgroup. But, the optgroup we want may not exist. So, we check to see if it does and if not, we create one.

    // Check to see if the optgroup exists. If it doesn't create it
    if (!optgroupMove)
    {
      var optgroupNew = document.createElement('OPTGROUP');
      optgroupNew.id = toID + optgroup.label;
      optgroupNew.label = optgroup.label;
      to.appendChild(optgroupNew);
      optgroupMove = document.getElementById(toID+optgroup.label);
    }

Now that we’re sure that we have an optgroup we can append our option to it. We also then add the old option to the deletedOptions array, as well as the provided hidden variable, if it exists.

    // Add our wayward option to the optgroup
    optgroupMove.appendChild(newOption);
    deletedOptions[index++] = option;
    if(hidden)
    {
      hidden.value = hidden.value + option.value + ',';
    }
  }
}

The final piece of the puzzle is to remove the option from the originating select. To do this we simply loop over the deleted options array, removing each option from its corresponding optgroup. This block also has the code to remove the optgroup if it’s empty. This is a bit finicky in how it works though. I’ll explain more below…

for (y = 0; y < deletedOptions.length; y++)
{
  var optgroup = deletedOptions[y].parentNode;
  optgroup.removeChild(deletedOptions[y]);
  /* The following removes the optgroup from the select if it is
   * empty. I made this optional because there is odd behavior
   * in the return from hasChildNodes if there is any whitespace at
   * all within the optgroup as it was orignally defined.  White space
   * constitutes a child node.
   */
  if(DELETE_OPTGROUPS && !optgroup.hasChildNodes())
  {
    var pNode = optgroup.parentNode;
    pNode.removeChild(optgroup);
  }
}

 

The problem with deleting the otpgroups (from what I’ve gathered so far) is that the hasChildNodes function will return true if there is any whitespace within the optgroup. In other words, when you define your optgroup, it has to be on one continuous line otherwise the whitespace is reported as a childnode and hasChildNodes returns true. This isn’t an issue if you populate your select through javascript but if you do it by hand or dynamically through php, jsp, etc. you’ll most likely put the whitespace in. If you don’t, then the delete will function appropriately.

Finally, the last piece is to deselect the selects so the have no options selected.

  // Unselect all options in both "to" and "from" select
  to.options.selectedIndex = -1;
  from.options.selectedIndex = -1;
}

And that’s it. View/test the code. Enjoy!

Google Web Toolkit

The Google Web Tookit Blog announced today that GWT has been released as a 100% open source product. I know many people in the OS community are probably hopping up and down with joy at this but I found myself with mixed feelings over the thing. Yes, releasing it open source is a good thing for the community and it guarantees that Google won’t do anything evil to me down the road after I’ve become entrenched in their product but it still makes me squeamish. Why? Because I’m not a huge fan of open source products. I think in the hands of capable companies like RedHat, it can be a good thing. Not necessarily is a good thing; just can be. Perhaps I’m worrying about it for no good reason but it sounds like a good way for Google to dump a product that they don’t want to support anymore. Hopefully, this isn’t the case. I really like the GWT. It’s a very handy tool. I’ve only got to use it once in a productional area but what I came up with was quite fun and GWT made it simple. So, am I excited about the opening up of GWT? Not really. Am I hopeful that, in the long run, it will be a good thing? Absolutely…

© 2024 friedcherries.org

Theme by Anders NorenUp ↑