[dev] [cvs] commit: ansel/lib api.php

Chuck Hagenbuch chuck at horde.org
Sun Jul 2 17:36:04 PDT 2006


Quoting Michael Rubinsky <mike at theupstairsroom.com>:

> I have a web site external to horde that I want to use ansel to manage
> some image content.  I'm using the functionality made available via
> the api to use an Ansel_Gallery seperate from the 'default' one that
> is used within horde (I don't want these images/galleries visable from
> within the ansel gui).
>
> I then have a config setting in my app, something like:
> $recent_images_gallery = 'myApp_recent_images'.  To make a long story
> short, images are uploaded from the app and stored in the
> $recent_images_gallery gallery.  Since I'm setting the $app parameter
> in the api calls, the Ansel_Gallery share is created as
> "horde.shares.myApp" and the gallery is created as a share under
> horde.shares.myApp as myApp_recent_images.  So in this case, the
> *only* way for this app to reference the gallery is  by the share
> name, which in this case is not a long md5 string.  The app checks for
> duplicates before creating the share and name collisions with
> galleries from ansel's own default share is avoided since we are in a
> different namespace so to speak.
>
> Yes, I could go into horde's datatree and manually find out the
> datatree_id for the gallery after it is created then go back into my
> app and use it, but it's not very convienient to have to check horde
> after each gallery is created.

So while I think it makes sense to use the datatree ids, I think we  
should "pretend" we don't they're datatree ids. They're just a gallery  
id.

So if in your app it's possible to create the gallery, have that  
gallery creation return a gallery id, ideally you should store that id  
and use it, thus letting us ignore the datatree_name completely. This  
is even better for the api, because we can move Ansel away from the  
datatree without breaking the API as long as we preserve gallery ids.

-chuck

-- 
"we are plastered to the windshield of the bus that is time." - Chris


More information about the dev mailing list