Recently at Amoebasys we worked with Media Machine to create a jQuery slider that integrated a Flash movie. Where the movie had to control the slider. This means that when the movie was playing it had to stop the auto sliding and start the slider again as soon as the video stopped.
The final solution is Flowplayer together with a really simple jQuery slider developed by CSS-Tricks called AnythingSlider. But getting to that took some interesting gymnastics and a couple of sliders later.
The problem with most of the really simple sliders is that it is very complicated to stop their auto sliding from outside and they also have really crappy functions, mostly everything is piled into one or two functions with a couple of useless options.
What I like about AnythingSlider is that is has all sorts of functions for playing/stopping, jumping between slides etc with functions that you can call with simple click functions. This makes some real sense in terms of building extensions onto it.
Even though AnythingSlider has this awesome API we still had to add some clever bits and pieces to it in order to allow Flowplayer to control the way it worked.
So as I said the final solution is a simple integration of Flowplayer and AnythingSlider with a couple of modifications to the AnythingSlider code. This allows us to play movies inline in the slider while still keeping full control of what the slider can do or not with Flowplayer.
I will write some more about it later when the client goes live.
It has been a while… I am apparently not dead yet, just terribly busy. The latest project I did with Amoebasys and Perceptum Though Squad was to create a way for Moodle users to automatically login to a Drupal site.
Simple huh? Erm… no
Since both Drupal and Moodle would be using the same database and would also be sitting on subdomain there were not too many complexities in that department. The problem was getting Moodle to create a cookie and then force Drupal to use it. Ideally I would like to have used oAuth or something nicer (I use this in the vaguest sense of the word), but there was no time to create clever solutions.
Basically the solution looks something like this:
Clever Drupal module that creates an API callback to sync Moodle Users into the Drupal database. An admin chooses which role you want to sync users from and which role you want to sync the user to.
A tiny little Moodle hack that creates and deletes a cookie that will tell Drupal which user to login and also to log a user out when the cookie is not available anymore. This is also only for that specific role that you select to sync to.
Then lastly there is a small Drupal hack that checks for the cookie and either logs a user in or logs a user out, depending on the content of the cookie.
Let me just say that I really REALLY hate writing hacks. They disagree with me completely down to my core but in this case I did not have the luxury of time to screw around trying to create a module that could do this. Perhaps the client will be happy to allow future development around the system. I would then definitely look at doing a more elegant solution with perhaps as I have said before, oAuth or LDAP at the very least.
At the moment the module is working well and there don’t appear to be any glaring bugs that we have been able to identify. So even though this is not an optimal solution I am very happy with it so far.
I will most likely write a more technical post at a later stage, but I am not 100% sure on the secrecy policy on the code