Closed (fixed)
Project:
Media API
Version:
5.x-5.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
19 Mar 2008 at 16:51 UTC
Updated:
20 Nov 2008 at 09:53 UTC
Since media items can be of several types and extensions, derivatives only can be created for certain types/extensions and presenters only can handle certain types/extensions, there is a need to combine type- and extension-specific display settings. Media_profiles.module or mapi_profiles.module (I am not sure yet which one is fitting our needs best) allows to create (display)profiles which contain type/extension-specific settings. Other modules can use these profiles to display media items without the need to specify which derivative/presenter to use per type/extension.
So it's just a small and simple module but makes things a lot easier (e.g. for the CCK formatters in media_cck.module).
My question is how to call this module (and with this how this module integrates with others): media_profiles.module or mapi_profiles.module? How does media_derivatives.module work? Does this one use derivative-settings of mapi_derivatives.module? When this is the case I think mapi_profiles.module is a good choice (especially because mapi.module has a greater scope than media.module in terms of flexibility and extendability.
Comments
Comment #1
rhys commentedSince I'm currently working on the mapi_derivatives now, I'm planning for this to function somewhat along the lines of the original media_derivatives. (And retiring the media_derivatives module).
The main thing that will change, is that the generated files can be placed elsewhere, through hooking, and therefore will be stored in the database in a slightly different manner.
I'm leaning towards it being mapi_profiles, since this would fit more with what it will be used for. media_profiles, would relate specifically to media installed operations, and I think it would have a use beyond simply the media module, as for instance, a seperately defined module, that wanted to utilize the profiles, but not have the media database processing take place.
I love the idea of the mapi_profiles, since this would provide a way for administrators to easily manage the settings, including override details for displaying, if necessary. To have this integrated into the mapi itself, I think provides the best solution to the potential problems coming up here.
I've got a clean install going, so I'm working out where the bugs lie for a new user. I've already run into some, that have relied on past version of the database, and hence require some fixes to bring them into line with the current system.
Comment #2
rhys commentedOk, so I figure the idea with mapi_profiles, should be that it would be possible to setup the presenter according to the required presentation. Also, it would be required to specify the derivative that would be in use. The biggest question I have, is there anything specific which would be required vis-a-vis the derivative itself?
It seems to me, the majority of what will be required by these profiles, is the ability to specify the way in which the presenter is to function, and which derivative it will be using.
Is there something I'm missing?
Comment #3
casey commentedYeah that's it. I can't come up with extra settings other than for presenter and derivative. When there would be more you could make it hookable.
Comment #4
casey commentedComment #5
rhys commentedProfiles exist now in the mapi module as a base feature.