We’re going to step things up a notch with this one, so hang on for the ride, because for those of you not already well versed in symfony and jQuery, there will be a lot of new information, and it will go pretty quickly, but I will try to make sure to keep everyone caught up. This is another post I hinted towards back when I first wrote about symfony widgets. Right, so, on to the fun!
First things first, let’s talk about requirements. My only real requirement is that it must be seamless. We must be able to only implement the widget, and have everything else work exactly as intended. For a date widget, this means when the user clicks that submit button, an array with ‘month’, ‘day’, and ‘year’ must be sent back. Not a string, not JSON, just that basic array.
It’s for the above reason that we will need to make a widget on top of the basic jQuery UI Datepicker Widget. The Datepicker alone would just return a string when we submitted the form, which would then require at least a custom validator, if not much more. So to simplify things later, we’ll put in more effort now.
There are four things we will be doing in this tutorial to make this happen. Here’s a quick overview:
We made our plugin, then we made the directory our jQuery plugins will go in, and the directory where we will store our widgets. The -p flag means “no error if existing, make parent directories as needed” which saved us a few mkdir commands.
3. Making our symfony widget
Now open up plugins/majaxWidgetPlugin/lib/widget/majaxWidgetFormDate.class.php and here’s our code:
So, to start out, we extend sfWidgetFormDate, as that will make the controls we need to manage a date submission. The only change we need to do, is to override the render function, which will let us add some custom code around the standard output, to allow us to more easily control the display.
4. Making our jQuery Plugin
As is the standard, I’ll show you the code, then highlight portions that are interesting. This file goes in plugins/majaxWidgetPlugin/web/js/jquery.majax.dateselector.js
You know, looking over, it’s pretty clear, I feel, what most parts do. The functions “_hide_real_ctrls”, and “_show_real_ctrls” hide and show that wrapping div we built around the original controls, so we can keep them in play, but not have to worry about controlling them. The “_build_facade” function builds our fake interactive Datepicker object, and optionally our ‘Clear’ button, if our date is allowed to be empty. Functions “_clear_display” and “_update_ctrls” to exactly as you would expect. Cure functions “_create” and “destroy” are from the jQuery UI Widget framework, and are called … can you guess when? 🙂
Once you’re done, you can replace any sfWidgetFormDate instance with a majaxWidgetFormDate instance, and everything else is handled. A little bit of effort up front, and many rewards down the road!
There are a number of options to consider when selecting a media player for a project. Recently, I had a large media panel to build and which player to use was likely the most important piece of the puzzle.
Here are the factors I used in determining which media player to use:
Speed – How fast did it load?
Interface – How easy was it to use?
API – How easy will it be for me to work with?
Documentation – How easy will it be for me to figure out how to work with it?
There are three players I considered primarily. There are many others I looked at, but these three were a clear cut above the rest.
Here’s the break-down of them, and we’ll start with the least compatible for the tasks I was trying to accomplish.
In a world moving rapidly towards trying to accomplish 100% cross-platform content compatibility, especially with the recent proliferation of HTML5, new tools are a constant need. MediaElement.js is a giant step forward in this area. It takes the hodgepodge of various presentations throughout the browsers, and consolidates them into one consistent presentation.
Very slick presentation. Allowing the control panel to be completely within the HTML/CSS means you can make any sort of change you need. As I’m planning to add at least one button later, that was a definite bonus.
Consistent presentation across platforms.
Allows us to use the HTML5 <video> and <audio> tags, to let the latest browsers handle the video natively and then allow us to fall back to other players for less capable browsers.
It supports both a fallback Flash and Silverlight player, for maximum ability to ensure video is displayed.
It was quite slow in my testing. The lag time between when an embedded <video> tag was detected and the video was ready to play, was extremely noticeable. It’s likely also due to loading up and then realize it needs to load a Flash or Silverlight player.
It didn’t handle dynamic changes very well. I think this could be solved by integrating it as a jQuery UI Widget as opposed to essentially just a basic wrapper routine.
What initially impressed me with Flowplayer was the promise it showed for extending the base display with html overlays to help add contextual information to the video. Then I started looking over the site, and noticed that the documentation is absolutely top notch. These guys aren’t playing around. Very impressive.
The documentation. Oh my … word.
The API. Not only is it very accessible and well thought out, it’s throughly documented.
Playlists. It’s something I missed when playing with MediaElement.js.
Have I mentioned that Flowplayer is well documented.
It’s huge. At roughly two times the size of JW Player, Flowplayer is the heavyweight of the bunch, which slows down that all important first page-load impression.
There’s some weirdness in it’s playlist system. When you push in a new playlist, the “cover image” isn’t loaded until you run play, which adds more delay between when the user initiates an action and when the player is where I will call “ready”.
JW Player is now on version 5.2. I first used it somewhere back in version 3, and as a disclosure, own an unlimited license for both versions 3 and 4. I have been consistently impressed by the flexibility of the player, and it’s ability to handle whatever I throw at it… once you figure out how to tell it what it wants to know.
Flexibility is the name of the game.
It did everything I wanted it to, in a way that I could live with.
It was lightweight and the quickest to go from page load to presentation.
The documentation could use some work. Instead of having answers at my finger tips, I had to search for them. Even for pretty basic things.
Some more descriptive errors might be nice, as opposed to things simply not working.
In the end, JW Player worked best for my purposes on this project, but every project is different, and I hope this helps some of you save some time.