Jump to:
| Project: | Embed |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Use this thread to track the status of the object element definition.
At the moment we have all the regular Form API properties (some of which are duplicated below to describe their specific purpose in embed):
Standard properties already defined in Drupal
#attributes - defines the object attributes. An array of key/value pairs. Collapsed to create the object.
#pre_render - defaults to embed_pre_render to handle preparation of the object / handling of multiple objects.
#post_render - used for post rendering operations (e.g. fall back functions)
#value - proposed location to hold alternate text content (on basis that for #type = markup this is where the content goes).
#theme - used to determine the theme that will be used to render the object. Normally left unassigned so we start in theme_object() and then that determines routing to other themes as necessary, and falls back to direct embedding as required.
New properties
#parameters - defines the object parameters - done.
#cacheable - flag to indicate if the handler should return cacheable content if it is able to do so. Not implemented yet.
#module_data - proposed property to allow modules to store data relating to their processing and communicate with each other. Would be an array keyed on the module that stored the data. Not implemented yet.
#metadata - proposed property to allow metadata to be communciated between objects. This could be very handy for ID3 metadata relating to audio, EXIF data relating to images for a gallery. Intended to allow modules to communicate metadata to allow playlists to be constructed etc
I think that's it for now.
Input welcome on the property names, purpose, and whether there are too many, or some missing.
Comments
#1
See also #434724: Refactor the object element to handle type specific properties which proposes adding additional "top level" elements based on the type of object, e.g. #stream / #version / #express_install / #flashvars for application/x-shockwave-flash.
#2
Using #value for alternate content has another attraction - if some sort of validation check fails such that the module knows the embedding will fail then it can just set the #type to markup, and then the content is already in the right place to be rendered as mark up.
For now I'm going to use #value as the alternate content field for the purposes of developing the module. It can always be moved later!
#3
Rather than populating the "top level" with arbitrary data would two parent fields, perhaps #object_data and #module_data (or #handler_data?) be better.
#object_data would store additional information about the object, maybe ID3 data, that the object is a stream
#module_data would be used to pass information to the handlers. We can find out what theme (handler) is going to be assigned, so something like SWF Tools could format its objects to pass parameters in to the handler in the right way. E.g. SWF Tools uses the variable image to define the thumbnail for a clip, but different players use different things. If we know where the object is going to end up we can try to pass the data in the right way.
This probably means that a handler module has its own set of defaults, but if the caller passes in something else via #module_data then this takes precedence.
I think I need to do some trials to work out the most logical flow here.
#4
Current status, reflecting implementation in the current CVS code.
#object_data presents an interesting idea now the audio and video tags are developing under HTML5. The audio tag supports attributes of autoplay, autobuffer, loop and controls. These aren't valid object attributes, so they shouldn't be placed in the #attributes array as we wouldn't know for sure if the object will be output through the audio tag. But we can provide settings via #object_data that a handler can choose to use. Ditto for video where we also have the poster element to define a thumbnail. We can therefore use HTML5 to define a "minimum" set of attributes we might like to pass to any available handler that it can choose to implement. It would make sense to support poster for audio content too since there is often a means in a flash audio player to display an image.
By referring to HTML5 specs there is a robust definition of how to create objects for rendering, and things like the audio tag defines a sensible small set of attributes that probably cover 90% of what is needed in most applications.