Re-writing the playlist module as a relationship toolkit for 4.7

Ryan, for #1,#2,#4, those would be defined by another *.module file. For our purposes, we'll define them in an audio_playlist.module file. Later on, if someone else wants to make a video_playlist.module or something, they can just plug in the same helper files again.

I imagine there'd be something like:

• playlist.install (creates the database table)
• playlist.inc (a file with all the helper functions)
• playlist.theme (theme_sort, theme_playlist, theme_manage)
• playlist.css (a css file for the themes)

those are the core files, then I'll probably include an audio playlist module to start:

• audio_playlist.module (creates an audio playlist using the files above)

So altogether, the playlist tarball package would contain 5 or so files.

Ok finished the playlist.install file thanks to Ryan. Ryan I just took what you submitted in the other thread and just added the extra 'type' column. I also think I'm near done with playlist.inc (might become playlist.module). Having it as a helper module would mean other modules could share the functions once it is turned on instead of having to worry about including it, or wondering which module has already included it.

Ok, finished playlist.theme and playlist.module I think. Basic toolkit is working, now to make an audio_playlist.module. I'm developing in my sandbox on CVS, if you are intersted in following or testing.

ok, audio_playlist.module is nearing completion. I still have to port over the feed functions, however. I also would like to incorporate a theme function to display a flash player with a select box for which playlist to listen to...

also, since the playlist.module uses generic theme functions, i have to think of some way for modules to send additional data for display, like the xspf player, or additional metadata. that way the same theme function can be used across the board by playlists.

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/zirafa/playli...

here is a link to the development sandbox

Ah, please don't change the title ;)

Yeah, the playlist.install needs some work. I'm not quite sure what you posted though. I'm not sure how to update from playlist 4.6 to this version since the schema is different. hmm....

Thanks for the comments, Drewish.

" in the table you've got an rid? what is that used for? it would seem like a joint key between parent and child would be fine..."
I guess I was thinking that a parent could potentially have multiple playlists. Don't know if this makes sense yet. But like if you have:

TYPE 'audio playlist' has parent 243 and child 65
TYPE 'audio and video playlist' has parent 243 and child 65

Currently the table is not used this way (and maybe shouldn't be)...especially if the rule is that a parent must be a unique playlist. But thinking in a broader relationship table sense it helps. Hmm I'll have to think about this...

"not a big deal but, in _playlist_save_order() for security clarity, you might want to cast the values from $_REQUEST to integers before passing them into playlist_set_weight()."

Would this work? Not sure if I can cast the entire array at once.

  $playlist_items = $_REQUEST['list'];
  foreach ($playlist_items as $child_id) {
  	playlist_set_weight($parent_id, (int)$child_id, $i++); 

  }

" i think remove is a better word than delete because neither the child or parent nodes are being deleted, they're being removed from the playlist. there's probably a better name than playlist_remove_type(), maybe playlist_remove_by_type(), something like that."

Good point. Remove makes more sense than delete.

"this is totally nit picky but the indenting/white space is really inconsistant, maybe you could tweak the tab/spaces settings in your editor."

True, I use Notepad2 ;) Any other editors you suggest? Notepad2 has a bizarre tab setting which I need to change.
But I'm also not sure what the spacing standards are so I end up doing willy nilly spacing.

Farsheed

Ok, I made the above changes as suggested by Drewish, except for getting rid of RID in the table...

Fixed formatting, changed playlist_delete -> playlist_remove, cast (int) on $_REQUEST['list']

I also fixed some bad SQL commands.

I plan on moving playlist_page back out of playlist.module, I don't think it belongs there because I can't generalize it enough and it has bad SQL.

I plan on merging Narkoba's podcast.module with audio_playlist.module.

Other things to do:

For audio_playlist.module:

• make the node name and description configurable (people have different names for the same thing, podcasts, audio playlists, music playlists, song playlists, albums)
• configure which feed links to display (m3u, pls, podcast, xspf)
• custom theme functions for displaying either an XSPF or RSS flash player
• blocks and pop-out flash players

Hi ryan, could you explain what this patch does? I'm a bit confused by node_playlist and node_playlist_item.

Thanks Ryan, I think I understand. I believe we would only need something like:

function playlist_update_1() {
   return _system_update_utf8(array('playlist_relate'));
}

It might be a good idea, when altering the 4.6 playlist table, to insert audio_playlist under the column, 'type'.

Coupet, Drewish, thanks for the File API links. I'll definitely be looking at how to integrate with these new ideas.

I also was thinking of some other ideas for modules that could build off the playlist.module. Since parent and child are just numbered values, we could have the parent id be an nid, but have the children be taxonomy term ids. Then, the playlist module would grab all nodes associated with those TIDs when generating a feed or displaying the feed. This way it could be used to make a smart playlist, so you just tag stuff and then it gets auto-added to a playlist and generates the desired feed or feeds. Maybe views could be incorporated with this.

ANYWAY! Back to getting this to work as is... ;)

Just some updates....

Got XSPF, PLS, M3U working great for audio playlist. I am finding having Narkoba's and Colin's album modules are great references and resources. I'm basically trying to combine and refine the best parts of everyone's code into one module. I'm also finding that having all the playlist_relate stuff in a separate module makes my life 10x easier and the code much easier to read through;)

Really the iTunes RSS specific stuff is what is holding me back. I am going to have to implement some extra node fields and a database schema to hold the iTunes metadata. Not really too difficult, but I've just been wading through the iTunes spec to make sure I get it right. Because of this, I'm planning on releasing the audio_playlist module as a separate module from playlist.module. It is getting much too big anyway and I don't want to clutter up playlist.module since it serves a more general purpose anyhow.

After I get the iTunes metadata in, the only thing left will be implementing some custom theme functions. That will be the really cool part, having pop-up flash players load in your playlist(s), or loading it up in a block.

OK! I'm finally done integrating everything I was hoping to for this release:

1) iTunes podcast/xspf/m3u/pls feeds generated on the fly, with full metadata support
2) album artwork can now be integrated (through URL)
3) xspf flash players for each feed, including popup players for each
4) audio browser, similar to iTunes, used to search audio tags and find the audio to add to playlists
5) upload new audio files to playlists on the fly with an inline uploader
6) listening station: an xspf flash player block that has a dropdown select to listen to different playlists on the site
7) Cut n' paste HTML and javascript includes for integrating the flash player on other sites

I will be uploading to to the main CVS repository soon and tagging it as 4.7. It still needs loads of testing, which by tagging it as 4.7 I hope will encourage people to try it out.

Farsheed

Hi Drewz,

Thanks for the bug reports!

The album art is supposed to be an absolute URL. It probably won't work with relative URLs. Eventually I'm thinking about integrating image_attach so that if an image is attached to the playlist it uses that as the album artwork instead of the URL.

I've only tested it with external images with absolute URLs.

Farsheed

Marking this as fixed. If you have any issues with the new 4.7 version of this module please file a separate bug report.