A new provider and a patches to allow emfield to support items with more than one result like flickr sets.

Attached is the new provider flickr_sets.inc (named flcikr_sets.inc.txt - so you need to rename it) which needs to be placed into emfield/contrib/image_ncck/providers and a patches to be run on emfield.module.

Please test and let me know if you hit any bugs, it should work with existing formatters (like lightbox2) so go wild :)

a_c_m

CommentFileSizeAuthor
flickr_sets.inc_.txt7.79 KBa_c_m
emfield.module.patch2.04 KBa_c_m

Comments

a_c_m’s picture

a_c_m commented
Status: Needs review » Needs work

I've just been thinking about how this provider works (and how multi result items work) and had a new idea. Currrently the module stores the sub items at creation, this means that if the (in this case) set changes, the item would need to be re-saved to get the update. Instead it should not store the sub items but generate them at display time... still test this version, as 90% of the code will stay - but i will submit a new one in the next few days.

a_c_m

aaron’s picture

aaron commented

be careful with that. it should be cached instead, because otherwise display might be too long if it has to wait for a response first.

a_c_m’s picture

a_c_m commented

Are they queries not cached anyway? How else can we insure the data is relatively up to date? i was thinking a cron job which fires every X hours or days, and loads then re-saves all the nodes which have a emfield with this provider type - but that gets ugly fast if there is a lot of data.

For flickr_sets its not so much of an issue, but after sets i want to do flickr_tags which for a popular tag could change very regularly.

I've not done any coding on this yet, so very open to ideas.

a_c_m

aaron’s picture

aaron commented

yes, they are cached by emfield. i misread what you wrote earlier, then. i thought you said it would fetch an xml update every display.

a_c_m’s picture

a_c_m commented
Status: Needs work » Needs review

As the header of the parent item is dependent (in flickr_sets case at least) on the number of sub items, and with there is already a update facility for re-freshing the emfield data - so i think the above patch stands :)

review away :)

SteveBennett’s picture

SteveBennett commented

where do I put the .module.patch file?

a_c_m’s picture

a_c_m commented

@SteveBennett: its a patch file, you need to apply it to the emfield.module file, details on how to apply patches are here : http://drupal.org/node/60108

alex ua’s picture

alex ua commented
Status: Needs review » Reviewed & tested by the community

Marking as rtbc (for 5.x, I may reopen for 6.x support). I'll be pushing 5.x changes later today. Any interest in porting this to 6, now that the Drupal 6 version is ready?

a_c_m’s picture

a_c_m commented

quite busy atm and dont have a D6 implementation, happy to offer help/support to anyone that does though. I'm in #drupal 24/7

aaron’s picture

aaron commented

the patch doesn't look like it'll be too difficult to adjust for d6. once i'm done editing my book next month, i'll have most my personal time freed up again, and can take a look at it (if it hasn't been ported already).

thanks for all the great work!

alex ua’s picture

alex ua commented
Version: 5.x-1.2 » 6.x-1.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

I'm putting this back on top of the issue queue in response to the conversation on g.d.o : FeedAPI + Flickr: Is there a guide? / http://groups.drupal.org/node/16799#comment-58327

aaron’s picture

aaron commented
Status: Patch (to be ported) » Fixed

I just committed http://drupal.org/project/media_flickr which now gives this capability (as a slideshow for emvideo).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.