[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