| Project: | Video |
| Version: | 4.7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
This patch separates the handling of remote and uploaded/local files. To do this, I created a video_type hook that modules can implement, which tells the video module about the video type. With this patch, which touches video.module and video_upload.module, there are two types ( I haven't split out the local files yet). But we have remote hosted (youtube/googlevideo) and uploaded.
Then, in the video settings page, the administrator can choose which is the default type. The default type is the one that gets listed at node/add/video. The module also registers a local task to that path for each video type. So right now, in addition to the node/add/video, there is also node/add/video/uploaded and node/add/video/remote with the default local task set as whichever one is chosen on the settings page.
The biggest reason for this patch is to simplify the video adding/editing page. For uploaded videos, there is no need to specify the filesize (and possibly the resolution, if mplayer is used for thumbnailing). So those should only be on the remote hosted files page.
| Attachment | Size |
|---|---|
| video_types.patch.txt | 15.46 KB |
Comments
#1
#2
Fabio,
Here is a new patch against the latest Video CVS. This is what I am running on my dev box with the latest Acidfree CVS as well. Something like this would be very nice since the two types of videos are VERY different and must be handled differently.
Try this patch out on top of the latest updates to head patch found in http://drupal.org/node/82224
#3
My patch for updates to HEAD was changed, which affects this patch as well. So here is a new patch that can be applied on top of that patch. The auto-thumbnail patch was unaffected by the changes.
#4
again, changes to the video updates to head patch made changes necessary in this patch. Here is the latest that goes with it.
#5
the simple menu title change that was applied to CVS for the updates to HEAD caused this patch to fail to apply. So here is a new version.
#6
There was one slight modification to this patch that I made to check that the video type extracted from the url was among the video types that we know of (uploaded or remote hosted). Other than that, this is mostly a 'nudge' to get people to try the patch out so we get get it moved from 'code needs review' to 'ready to be committed'.
Please review and apply.
#7
Well.. we definitely need differentiation on video types...
You approach is good and efficient however I would like to create something
more extensible...
I was thinking about doing the same thing I did with plugins also for video sources.
This will create a subfolder called "video_types" which contains modules such as
video_youtube.module, video_remote.module, video_upload.module...
Then we will use multistep forms: we the user go to node/add/video a select form
will be rendered .. the user is asked to choose the kind of video he is going to create.
What do you think about this?
Fabio
#8
I am _very_ opposed to multi-step forms. If it can't be done in one step, it is probably too difficult for most users. I am speaking of the 'Homer Simpsons' of the world. They are the majority of the website users in the world. You, me, and the rest of the Drupal programming community needs to keep this in mind when we create the user interfaces. They really need to be 'Homer proof' or Drupal will not be able to keep its hold and will fall from grace. I take you you don't want the local-tasks version?
But yes, something more extensible. I actually had some doubts about my version of the patch just last night when I was working on stuff. I haven't really come up with any better ideas yet.
#9
I was thinking about something simple.. not too complex. Just a dropdown to select the video type,
similar to http://drupal.org/node/add/project_issue
Can Homer do this? :-)
Yes we have to think about this... I will analyze the problem, and report my ideas.
Fabio
#10
Well, personally, I think adding and issue would scare the pants off Homer, but I figure that is okay for the project module because the people who are using it are mostly developers or web administrators.
I suppose a drop down is a better idea than the local task tabs.
#11
I'm developing something like the attached picture.
I'm splitting different video types into submodules.
This should make coding easier.
#12
I'm developing something like the attached picture.
I'm splitting different video types into submodules.
This should make coding easier.
#13
Could I get a patch for this latest change so I can test it out?
The reason I wanted to be able to handle this differently was so that I could have Acidfree use form alter to simplify the add/edit video pages. With Acidfree, I want most stuff to be automatic -- thumbnailing, video information, etc. -- so that the user can simply give a file and a title (or just a file with mass import) and it will create a fully populated video node.
If splitting the video types into separate pages simplifies the forms sufficiently, there is no real need for a form_alter hook for Acidfree, which makes my life eaiser. :) Plus I think it makes the UI better.
#14
finally implemented. going to publish it soon.
Fabio
#15