Refactor the object element to handle type specific properties [#434724]

Flash content is the main thing that is driving this module at the moment, although it can clearly handle other types too.

The issue with flash, although good in this case as it helps us try to get the module right, is that it has a few interesting aspects we need to handle.

Specifically, flashvars, express install, and streaming.

To handle each of these the modules need to know how they are going to receive the information.

At the moment flashvars are tucked under #parameters as an array, but with hindsight that maybe isn't quite right - we generate the markup for the page by imploding the array of parameters, and having an array in there causes a problem. Basic embedding does a pre-render step of imploding that flashvars array to a single string, and putting that back in to parameters.

I think what I would prefer to do is define some additional 'top level' properties, but these will ultimately vary by type of object. I don't think that's an issue since we are only adding properties to our own object element - we're not adding them to all types.

I did wonder about collecting all such properties under a common heading, but I can't think of a suitable title. If there's no good reason they shouldn't just sit at the top then lets put them there!

So, for flash, we would have additional flash specific top level properties of

#flashvars : an array of flashvars. This is then processed by the rendering method. Having this as top level saves us unsetting it in #parameter, and for modules that can implement JavaScript rendering we can just give them this array.
#express_install : a path to the express installer file, or if just set to TRUE then if the renderer is capable it can fallback to its own method (thinking of SWF Object which comes with a default express handler). This maybe needs to default to TRUE, and have a setting on the configuration page for the handler.
#stream : for streamed content the path to the streaming server goes in here. Player modules take this parameter and re-assign wherever they need, probably to a flashvar. Again, placing it at the top makes it easy to access in code.

This model then extends quite well to other (as yet undefined) content types, where we can add their own special property sets too.

Does anyone have any strong thoughts on this?

Comments

Comment #1

Stuart Greenfield commented 15 April 2009 at 20:11

Hmm, would also need

#version : minimum version of flash needed, if the caller needs to set. May be necessary to set this with player modules that expect a certain flash level to operate.

Comment #2

Stuart Greenfield commented 3 September 2009 at 22:20

As per other threads, the code on CVS proposes #object_data as a top level container for information about the object, but that isn't an HTML attribute. Version sits logically in here, although not yet implemented in the developing code. Stream also sits here, and is implemented in the prototype flowplayer module. Flashvars is also being handled through #object_data.

As a solution this seems neat as it means when the #attributes array is collapsed for output we don't have to worry about it containing invalid attributes that will cause page validation to break. The #attributes array (should) only contain valid HTML attributes, although we don't actually validate that this is the case. #object_data is now "optional" - a handler can use it, or ignore it.