[drupal-devel] [ann] flickr_block.module
Jeff Griffiths
anisotropic at gmail.com
Sun Aug 7 17:50:06 UTC 2005
I'll take a look at your code and see if there is some commonality
with a per-user flickr photo gallery module I am (allegedly) working
on. ideally the same back end for wrangling flickr calls would be
used.
JeffG
On 8/6/05, Kristjan Jansen <kristjan.jansen at gmail.com> wrote:
> I contributed a flickr_block.module. Since I am crippled with day
> job, perhaps somebody wants to move on with this project? Jonas?
>
> Screenshot
> ----------------
> http://trip.ee/files/images//flickr_block_demo.png
>
> Readme
> ------------
> http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/flickr_block/README.txt
> :
> Flickrblock is a simple module what generates blocks of Flickr images.
> It is proof-of-concept and not yet ready for mainstream use (no proper
> access control and
> error handling yet)
>
> Currently 2 blocks are generated:
>
> * 'Related Flickr Images' will show up on taxonomy/term/x pages. In
> addition for term name, the synonyms are also considered (should also
> 'related terms' be matched?) The block is useful f.e. travel sites
> where in each destination page the related images are shown in
> sidebar, http://www.43places.com and http://technorati.com style
>
> * 'My latest Flickr images' shows just stream of latest images added,
> matching the Flickr ID
>
> Fetching the XML is done by Drupal's new excellent xmlrpc() function,
> it is favoured over REST because of cleaner code (oh please make the
> 'external l()' patch to the core ;)
>
> PHP parsing is done by xml_parse_into_struct() and helper function
> that converts the
> struct into a a more usable nested array. The array structure might be
> too complicated
> though, looking for suggestions for simplifing the structure
>
>
> Demo
> --------
> http://kika.trip.ee (unstable now, come back later)
>
>
> Todo & Future
> -------------
>
> * 'See more pictures' link
> * CC licence link
> * access control
> * error handling
> * caching (should we cache xml, transformed array or images?)
> * CSS classes
> * image theme/CSS unification with image.module
> * introduce configuration
> * number of images be fetched
> * move all flickr paths to configuration (they have changed their
> url schemas already!)
> * more blocks
> * blog block (requires separate flick_user_id for each user);
> * my latest photosets
> * testing, testing, testing
>
>
> In future, I'd like to see this module integrated to Jonas' flickr.module
> http://drupal.org/node/14912 after some more integration:
>
> * unified naming conventions
> * unified configuration
> * unified xml parsing
> * unified caching
>
>
> k
>
More information about the drupal-devel
mailing list