[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