Positioning categories & subcategories!
rutt
Registered Users Posts: 6,511 Major grins
This time I have answers and a suggestion instead of just stupid questions.
Ben answered an email of mine and cleared up how this works. The position of a category or subcategory is the minimum of the positions of all its galleries. There was some pilot error in my examples that confused me.
With this knowledge in hand, I've been thinking about being able to position categories and subcategories. It's pretty simple, really; it can be done now through the API, but it's a lot slower than it needs to be. In order to position (sub)category B between A and C, just make sure that all the galleries in A. have smaller positions than all the galleries in B and all the galleries in B have smaller positions than all the galleries in C. An algorithm to sort all the categories in any random order while maintaining the relative internal positions of their galleries is fairly simple given the number of galleries in each category and their initial positions. We just have to calculate a (possibly negative) constant for each category and add it to the position of all the member galleries.
For example, to invert the order of galleries A and B from A,B to B,A, we need to know Max(position(B)), the maximum position of any gallery in B. Then we just add Max(position(b)+1 to the positions of all the galleries in A.
The problem is that this takes a lot more API calls than necessary. Even supposing that we cache the gallery positions, we still have to make one API call per gallery that we want to move. In order to be able to move categories to arbitray relative positions, this potenitally requires a call for (nearly?) all of a user's galleries.
I think this is a useful enough thing that it would be worth some hooks to speed it up. It's easy to come up with some primitives to support doing this quickly.
The same idea could be used to implement positioning of (sub)categories though the smugmug web interface. This is a feature I've often wished for.
Ben answered an email of mine and cleared up how this works. The position of a category or subcategory is the minimum of the positions of all its galleries. There was some pilot error in my examples that confused me.
With this knowledge in hand, I've been thinking about being able to position categories and subcategories. It's pretty simple, really; it can be done now through the API, but it's a lot slower than it needs to be. In order to position (sub)category B between A and C, just make sure that all the galleries in A. have smaller positions than all the galleries in B and all the galleries in B have smaller positions than all the galleries in C. An algorithm to sort all the categories in any random order while maintaining the relative internal positions of their galleries is fairly simple given the number of galleries in each category and their initial positions. We just have to calculate a (possibly negative) constant for each category and add it to the position of all the member galleries.
For example, to invert the order of galleries A and B from A,B to B,A, we need to know Max(position(B)), the maximum position of any gallery in B. Then we just add Max(position(b)+1 to the positions of all the galleries in A.
The problem is that this takes a lot more API calls than necessary. Even supposing that we cache the gallery positions, we still have to make one API call per gallery that we want to move. In order to be able to move categories to arbitray relative positions, this potenitally requires a call for (nearly?) all of a user's galleries.
I think this is a useful enough thing that it would be worth some hooks to speed it up. It's easy to come up with some primitives to support doing this quickly.
- Get minimum and maximum positions for all the galleries in a (sub)category.
- Increment/decrement all galleries in a (sub) category by a constant
The same idea could be used to implement positioning of (sub)categories though the smugmug web interface. This is a feature I've often wished for.
If not now, when?
0
Comments
You've nailed it on the head, at least as far as ordering goes.
We've been toying with a tool for the web interface that does exactly what you describe. When it'll see the light of day, I don't know, but it will at some point.
I'm not entirely convinced that making a bunch of calls for each gallery is necessarily all that slow, though. If you open an HTTP socket and keep it open, rather than closing and reopening each call, it should be pretty fast - updating a gallery's position is a pretty fast request on our side.
Maybe not ideal - but certainly faster than waiting for me to build a method for this.
Don
I got an exception while using setInfo the other night. It said system fault. After I was careful to make sure not to set any positions to the values they aready had, it went away. But I'm not really sure that that's all I did. Should I be able to set a position to ANY integer? Any positive integer? What's the allowable range?
I'll love the web interface. As I said, I've been wanting it for a while. How slow or fast this is really depends on how many galleries are involved. For (sub) categories with not many gallereies, no problem. I think that might ususally be the case. But I have at least one category with thousands of galleries. (It's all my proofsheets.) I think a working sports/event/portrait photographer could accumulate a lot of galleries in each of several catagories, one of each shoot, say.
I did order all my galleries the other night and it took about 1/2 hour. No gzip then and no new heavy calls, which should help. And wasn't careful about timing it. After Don answers my nits about position, I'll try again and report more careful times.
Ties can occur, won't be rejected, and are automatically resolved and renumbered. Tied numbers will reside next to each other. I don't have time to dig into the logic, but it probably just chooses based on AlbumID.
They will not (should not?) be tied after the submission is complete.
Don
Don, you are right about this. After all the good advice from studiocells, I now have a python xmlrpc that both uses gzip and persists the connection. I repositioned 602 albums in about 5.5 minutes, which isn't exactly instant, but not so bad either. So at least it's doable.
Now I think it would be awesome to have some "mapping" operations that are a more flexible than just what's required to repostion categories relative to one another. I'm sure this will require quite a bit of thought, though.