Category & SubCategory Position attribute - missing

ebswift

SmugMug 1.2.2 API

Hi, there seems to be an omission in the API of the category & subcategory positions. This actually presents two problems.

Firstly, you can't display categories & subcategories in an external app in the order the owner arranged them in.

Secondly, category feature photos will not be displayed as the owner intended if they are using the first album from the first subcategory to derive the feature, -and- the first album of the category does not contain a feature.

To fix this, I propose that a new Position attribute be added to Category and SubCategory in gettree calls. Position should probably also be available in categories.get.

ebswift

Looking back I've had a number of people reporting issues related to this via my application. I think it's actually a showstopper for some pro users - they have less tolerance for deviation from their preferred gallery setup.

mattwright

try smugmug.albums.get?

ebswift wrote:

Hi, there seems to be an omission in the API of the category & subcategory positions.

I have solved this by doing a smugmug.albums.get that includes the category/subcategory information. As best I can tell, this will return items in a manner sorted the same as the user's online gallery. You can then discard completely the "Position" parameter of the album and just create your own based on the order in which albums are returned.

Let me know if you find users for whom this is not the case, as then my app will also be broken.

Matt

ebswift

Thanks Matt. This may work as long as all the same info exists as it does in gettree.

I still think it makes good design sense to include the category & subcategory position attribute in gettree though, otherwise you are presenting albums in position order whilst categories & subcategories are fixed in their created order - regardless of what type of application you are creating.

devbobo

I recommend that you use the method that Matt suggested.

We have a some changes planned for the near-ish future...that add a whole new dimension to categories and subcategories. So given that, I'm not going to implement position now as you will get that and more when we implement the changes.

mattwright

ebswift wrote:

I still think it makes good design sense to include the category & subcategory position attribute in gettree though, otherwise you are presenting albums in position order whilst categories & subcategories are fixed in their created order - regardless of what type of application you are creating.

FYI, I am suggesting using the album order to determine category order. So this is how I did it:

Use smugmug.albums.get to retrieve a list of albums. This list appears to be in a depth-first search order of what the user would see in their category tree as sorted on their site. Assign each album a "Position" as you encounter it, incrementing as you go along. Each time you encounter a new category or subcategory, assign the position for that album to the category or subcategory. Your category and subcategory now have the position of the first album in that category.

Now, when you sort your tree, order the categories and subcategories by the position variable to assigned them, ensuring that top level categories are pulled before subcategories. You can then just order the subcategories within each category according to the position variable and it should work out, at least from my testing.

Keep in mind that when I refer to the position variable above, I am always talking about the one you generate, not the one the API returns. I thought I could just use the one the API returned, but then I ran across a user who had an account that was returning really weird position parameters. Let me kow if I need to explain any of it in more detail or you find accounts that are exceptions to this behavior.

Matt

ebswift

Cheers Matt. I'm using a database caching mechanism - recording all the data then using SQL to get everything back in order, so it should work out OK after I rewrite the read method.

Thanks David, always looking forward to newer & better API releases.