Jump to:
| Project: | FileField |
| Version: | 5.x-2.3-rc2 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Greetings,
I'm a developer of mediafield.module which is quite old and I'm going to redevelop it.
I found that you created a filefield API which gives an ability to support different types of files.
filefield_meta.module is an example of this.
I would be interesting in redeveloping mediafield (which is a pair of audiofield and videofield) as two plugins for filefield.
I found that you do module_invoke_all('filefield', ...)
This means that all modules implementing filefield API will be called.
I'm not sure this is a right approach for me. Audio and Video fields must have different widgets (flash audio and video players), they will have different meta information processing and different storages for it.
My question is - are you going to improve somehow filefield API so that it is possible to create such plugins. If not audio and video fields will stay as they are, but in this case I would like to use some code from filefield in order not to duplicate code.
Comments
#1
The newer versions of filefield and derivative that should be coming up in production soon will probably make your fields easier to support.. check out the fieldfield_meta module as a way to simplify and unify the ui's so each type doesn't have so many ui differences...
I always hated all the additional user input required for different media types... You can also use the form op of hook_filefield to alter the file forms based on file type... I've already done a lot of the work to replace those additional modules and should be releasing it in the next week.
#2
I would prefer to work on merging the work and developing upgrade paths, but some of my approaches may be very different from video/audio/mediafield. However alternatives to breed innovation. I don't expect my approach to work for everybody, but I hope it will work for most use cases. I'm more interested in unifying work on file related stuff. Code developed around hook_filefield should also be easily portable to the proposed hook_file for core at http://www.drupal.org/node/142995
#3
Well, audiofield module need to create table columns different from the ones created by videofield module
I want them to store detailed information about video/audio files. Is it possible with hook_filefield?
#4
absolutely, see filefield_meta as an example. It should be in the filefield cvs.
#5
Thanks, I have reviewed this module closely and everything is clear now.
Nevertheless, there is one question still:
In current architecture hook_filefield is called for all modules (module_invoke_all) for every file field in the project. I have 2 content types. The 1st one has an audio field and the 2d one has video field. I don't want both processing are performed for both fields. Ideally, I want to somehow specify the 1st file field to use audio processing (and no other), the 2d field use video processing. But these fields are all 'filefield' with the same widget. I also need two separate theme functions - one for audio and one for video fields. More than, I want to implement audio/video players from SWFTools as formatters, so that user can easily specify which player to use for which field.
The only solution I see now is to create Audio, Video widgets for file field, and my own formatters. But in this case I will duplicate some code from filefield/module. Your thoughts?
#6
hmm... I'm taking a different approach in my development... I want to detect the filetype being displayed and use that to decide what to render with the multimedia widgets I want to develop. Also have formatters that are smart enough to figure out how to display things, but these are a little more difficult to make happen, you have to write an interface to create settings for formatters.
I'll try to commit the most recent derivative module as an example tonight.
#7
FYI, I've been examining the hooks as a possible route to better provide local file support for Embedded Media Field as well. I'll keep you posted.
#8
We were just talking about how the functionality the audio module has could/should be rolled into a cck field. This seems like the right place.
#9
Well, this a good approach but won't it become an attempt to develop your own formatter? Why not to utilize such CCK features like widgets and formatters? I'm not sure this will work but this is just a proposition.
Instead of file type detection, user may choose a File Field widget which will process uploaded file in a different manner depending on file type. To choose how to present this file a user will choose a formatter. We may have several formatters for video and audio players. But how to prevent user from choosing a video formatter for audio file? So, may be creating your own API such as hook_filefield_formatter() or hook_filefield_widget() is a good idea.
This is still an issue in CCK. They have settings for widgtes but have no settings for formatters which is a big loss.
#10
I'm am using CCK's features for widgets and formatters... You can still choose a formatter, but one formatter will be capable of displaying any file maybe? not sure just yet.. still mulling over what kind of ui it should be in all honesty...
For the input side... What I consider a widget would be basic html form upload, existing files browser, some java applet uploader, some flash uploader, etc... FileField meta having a fairly unnormalized table to easily expose common metadata for all files to views, and not weigh down the most basic file handling... Derivative module using transformer to create derivatives and formatters... I've got more of it uploaded... I still need to remove the hardcoded call to my ffmpeg class from it, and replace it with a more general media class...
#11
+1 for all of the work that's going on here. I'm currently the maintainer for Mediafield Display, and I'd be more than happy to deprecate it if all of the audio Flash playing is present in this module, FileField.
In the next little while, I'm sure we could cut down the huge list of media modules to FileField, Media Mover and Asset. And then when that's all done, we could merge those together. ;)
I spent a fair amount of time talking with the maintainers of Media Mover and Asset at Drupalcon, and those projects seems to be coming along nicely. Media Mover works with attachments while FileField works with CCK. Either of those seem valid to me, especially now that Media Mover can work with views (IIRC).
#12
Exactly! I would love to have less modules but with better functionality and wide range of features.
I'm try to understand now what is a better way to implement different media files. It is good that filefield will be a base of all files (may be except for imagefield for now). But I'm sure every type of media file needs the same upload form element, its own parsing mechanism, specific output for upload form and specific outut for a view page (players).
Initially, I had an idea that all media files should have their own different fields and use the same file API (implemented in filefield). Now I think we can have one field with a set of widgets/formatters.
CCK widgets will be used to provide specific form elements and players will be implemented as formatters. We also need to have a specific parsing which must be performed only once (upon upload). Dopry developed his own API to perform that.
#13
I've just recently started using Drupal (2-3 months ago) and I'm quite happy to see such a discussion. I know that better media handling is planned for Drupal 7, and I'm quite eager to see the various solutions to handle media merged into something more cohesive.
Although I lack the experience, I feel that a CCK based (using FileField as a basic type) with various widgets and formatters (for the display/output part) would make for a pretty nice/flexible solution.
I won't probably be able to contribute in the coding department, but i'd gladly provide testing/feedback time.
#14
Cool.. You're getting on my bus now :) One filefield supporting all media type. Specific modules that alter the UI depending on the file type with a common upload interface... That is how the filefield/hook_filefield family of modules is designed.
I'm doing some more cleanup on them this week.. I'm implementing it for another site, so it gets a little more TLC now.
#15
I'm wondering...
If I would like to start working on some widgets (UI) to help support the integration of some media type with FileField, where should I be heading first? (documentation, coding standards... and so on).
I'm quite comfortable with html/CSS, javascript (and jQuery), flash(actionscript) and the whole server-side scripting idea but I'm fairly new to Drupal and PHP development. It would be a big overstatement to say that I'm comfortable as where and how to contribute to help push those ideas forward so any pointers as to where to start would be appreciated.
Thanks
#16
mockups so people can visualize what you're presenting are great... docs are great as well... I would proposed changes as feature requests... Add mockups and a description of the UI changes you propose.... It' will make them easier to consider and implement...
#17
sorry, tired of waiting.
i just added Audio Filefield to the fray. this hooks into filefield and getid3, automatically detecting if a file is audio/mpeg, and taking over from there.
it's still in development. what it does this moment: detects audio/mpeg files and saves some info such as bitrate, sampling, playtime, etc. it saves and does nothing extra if the file is not audio/mpeg. what it also should do by mid-next week: store other meta tags, such as artist, year, etc; allow admin to set what tags to save; add view filters by metatags.
for now, i'm not going to bother with theming, and rather direct people to use jquery media, which will automatically convert a file link to audio or video as appropriate.
a couple of things that would be helpful from filefield:
* expand hook_filefield to allow us to modify widget settings (so, for instance, we can specify what tags to store for an individual field ala audio module)
* same for field_settings; i'd love to be able to add my own filters. and even tap into cck for db columns, rather than having to create new tag tables manually on the fly
for now, i'll just use form_alter, and switch over when/if better support is provided.
if someone gets around to writing a superior version of this, i'll be glad to provide an upgrade path and deprecate the module.
thanks for all the hard work, guys!
aaron winborn
#18
created a feature request (with a patch) at http://drupal.org/node/255328 for this ability.
#19
I like the way this is headed... i'm going to download Audio Filefield now and have a play.
#20
I've recently become the maintainer of the MediaField module, mostly because i was bored of having to apply the same few patches every time i went to use the module - however i fully support the deprecation/re-writing of this module in favor of MediaMover and FileField+formaters approach. I've still not had a chance to play with the Audio FileField, but plan to shortly.
For what its worth I think keeping the formatter modules separate is a good idea, allowing people to pick an choose which add ons they want to install as well as not over stretching the developers of Filefield. Perhaps MediaField could become the home of the Audio FileField and Video FileField modules, this would allow us to bring on board exsisting MediaField users (but the upgrade path might be more difficult?).
Anyway, like i said before, i like the way this is headed.
a_c_m
#21
See filefield 3.x if you're looking for a D6 solution... It's possible in D5 with form_alter and hook_filefield....
File issues if you come across specific bugs in that hook, but there are no specific issues to address here and I'm closing it.