the 'library' tab will probably need to be replicated for other solutions, such as 'my youtube videos', views integration, and the like. we should ensure there's either an easy way for developers to feed a query and return a list of thumbnails, or document the best way to do this.

Comments

aaron’s picture

i'm digging into media.library.js, and it looks like calling media/browser/list with conditions as the parameters will do what we need. i need to figure out how to extend Drupal.media.browser.plugin.library to do what i want...

aaron’s picture

Status: Active » Needs work

i changed media_browser_list() to actually parse conditions from the passed json $_GET query. then also added support for stream filtering. note that it couldn't be passed as a condition, as LIKE requires three parameters to conditions. for now, i have a hacked up version that will filter the entity_load on $fid's returned from a manual query. however, this will choke unless we add pager support. needs a lot of love.

aaron’s picture

Status: Needs work » Active

proof of concept is checked into media: youtube now as well (the 'youtube library' tab). i know there's a better way to do all this, this is just to get that process started.

aaron’s picture

Status: Active » Needs work

gah! cross-posted myself... :P changing status again

JacobSingh’s picture

Woah, that's a big and important change! I'm excited to check this out.

It might make sense at this point to throw up a mockup of what these type of features (filtering, etc) will look like and discuss. I can give you access to that mockup tool I used to build the first one if you want.

-J

aaron’s picture

one issue i'm concerned about is i'd like to use vertical tabs on this page. however, the library page is built entirely from javascript, which makes that difficult at best...

JacobSingh’s picture

Title: replicate library tab » Add filters to library tab (what filters?)

Okay, I looked at the _list function. It's great that headway is being made here, this will really be an awesome addition. Selecting all the fids first seems like the wrong approach though. Entities have controller classes which we can declare if we need to more complex filters than what $conditions supplies. They get passed into the ->load($ids, $conditions) function which will handle it. We should extend the default controller with a Media one.

Loading each media entity one-by-one will be really slow, and while not totally unacceptable if being done with a pager, I think we should endevour to use the tools provided for querying multiple entities.

I think we need to reset what it is for. In terms of conditions and filters, there are various ways to do this, but I'd like to keep the functionality really light and to be honest, hardcoded in the core module. Someone will write kick-ass views for this, and they will supplant whatever we put together. I think that's great, and it means I don't have to re-write views in our callback :) Not great for my job because Gardens isn't using views, but inevitable IMO.

So is this issue "replicate the library tab" or "make filter on library tab for X"?

Where X could be by stream type, or by media type or by extension, or by size, etc?

Personally, I think we can quickly make a mess of a nice clean interface here, so it is important to be able to turn filters off - also to mock it up first.

I'd vote for just doing type and a wildcard search on uri (so you could support something like youtube://*). These could be passed in by callsites and could also be declared as visible / not visible by callsites so we launch a "video only" browser, etc.

Thoughts?

Re: Vertical tabs: This goes into the larger discussion of FAPI-ization I think. But at a higher level, are we sure that's what we want? They take up quite a bit of horizontal space. What about Finder style search rows under the tabs?

aaron’s picture

"Loading each media entity one-by-one will be really slow, and while not totally unacceptable if being done with a pager, I think we should endevour to use the tools provided for querying multiple entities."

this is just how node_load and node_load_multiple work, which is where i snagged the code. but i'm all for improvements.

"I'd vote for just doing type and a wildcard search on uri (so you could support something like youtube://*)."

it's currently doing a wildcard search on uri; that's the @param $stream i'm sending in right now. in fact, it was specifically for that functionality that i have it loading the fids first: entity_load doesn't support ->like conditions, unfortunately. :( though i guess we could always submit a patch (or write our own function to handle that).

"Re: Vertical tabs: This goes into the larger discussion of FAPI-ization I think. But at a higher level, are we sure that's what we want? They take up quite a bit of horizontal space. What about Finder style search rows under the tabs?"

good ideas as well. belongs in another ticket though.

JacobSingh’s picture

We discussed the EntityController during our meeting. Remember? It's the one where we can extend the based entity controller, and provide a different load mechanism? I think we agreed to use it, and I said i'd implement this, but I haven't had time since Wed night.

Also, we might want to consider using:
http://drupal.org/project/entity
I don't know much about it, but it looks like it might help us reduce duplicate effort.

Anyway:

The entity API is very cool, very much part of everything core, and we've really got to use it here.
See includes/entity.inc for the Interface and the base class (DrupalDefaultEntityController)
which we are using. It's actually quite simple.
Just make a new one

class MediaEntitiyController extends DrupalDefaultEntityController {
  function load($ids = array(), $conditions = array(), $any_other_var_your want) {
    // custom code here which does the same thing as the parent
    parent::load($ids, $conditions) // if you want to.
  }
}

and in hook_entity_info, just declare that we want to use our controller, not the base one.

Best,
Jacob

aaron’s picture

ah, great. we should definitely go this route -- overloading the class is a better way to deal with the stream filtering in particular. and once we add ->like conditions, we can go back to the extended entity_load. (would that become simply media_load?)

JacobSingh’s picture

Okay, so I've added a filtering framework here, we've just got to build out interfaces for some filters and perhaps a 2nd library tab? I'll outline some ideas in another issue.

Should we keep this one going?

Dave Reid’s picture

Version: » 7.x-1.x-dev

I'm not sure how this is relevant anymore with the switch to file fields - especially if we add proper Views integration that replaces the custom media browser. We then get built-in filtering and ajax paging.

See #1224766: Remove default media browser and replace with a default view

Dave Reid’s picture

Component: Code » Media Browser
effulgentsia’s picture

Status: Needs work » Closed (won't fix)

Sparked by a client request, I recently looked a bit into this, and concluded it's not worth the bother to get this done in 1.x. Here's why, along with some info if someone else wants to take this on.

----------
The 1.x media browser code is an iframe, and the AJAX interactions are all done via custom JS code and PHP code interaction: not using the D7 AJAX framework at all. media_media_browser_plugin_view() contains the plugin's definition of the library tab. There, it has the #markup property into which you can add HTML, like text input fields. Then, you can figure out what's going on in media.library.js to make the filter work. A starting point here is Drupal.media.browser.library.prototype.loadMedia() which initiates the jQuery.ajax() request whenever the scroll bar is at the bottom in order to fetch more items. Note the "data: this.params" part. You can add more stuff to this to send the server info about the filter values. Then where media_browser_list() sets up $query, you can add more modifiers as you need to to the query.
----------

So, while hacking in some specific use-case is theoretically possible, it's kind of a pain, and the current media browser code just doesn't lend itself to solving this in any kind of generic way.

However, #1139514: Overhaul the media browser code to not use an iframe, and be more understandable, maintainable, and extendable is all about fixing this old media browser code into something sustainable, and once that's done, #1224766: Remove default media browser and replace with a default view will be cleared to replace the library tab with a View, enabling the administrator to customize it in all the cool ways you can customize a View (exposed filters, paging, ...). That's all slated for the 2.x branch now.

Note, I'm marking this issue "won't fix", because I'm pretty sure that none of the people who've participated on it so far plan to work on it, given that what we really want to work on is the Views integration. However, if someone wants to work on a non-Views solution for 1.x, go ahead and reopen this issue.