Community
Participate
Working Groups
Workbench needs to provide utility mechanisms that can help clients determine dependencies between sets of activities and categories.
From 80130: 2) apis that allow the following: given a category, give me all categories that will be enabled/disabled if this category is enabled/disabled. For Atlantic, we needed to prompt the user with a list of categories (aka roles) that will be enabled if he enabled a certain category. This was a bit difficult with the current apis because I had to do the logic of taking the current category, looking at all its activities (and all there dependant activities) and figuring out given this set of newly enabled activities, what categories will be enabled. an api would be great. 3) apis that allow the following: given a activity, tell me whether or not I can disable this activity. Again, we needed to know this because if a user disabled a category we did NOT want to disable other categories under the hood. We did not even want to prompt the user. He does not need to know. So, we had to, given a list of activities from the category we wanted to disable, we had to figure out if there is any enabled category that had any of these activities enabled. if yes, then we did not disable this activity when disabling the category, because disabling this activity disabled another category and we did not want that. Again, an api would have made sense here.
Some initial code in head in WorkbenchActivityHelper. You can ask the helper what categories will be enabled/disabled if a given category is enabled. I went with the assumption (correct me if I'm wrong) that you would only be interested in categories that would actually change if the given category is changed. Ie: if the given category is already disabled then don't return it in the list of those that would be disabled. Hope that makes sense.
Mazen: For point 3 above, would a method such as Set getEnabledCategoriesForActivity(String activityId) be sufficient? It would return the set of all fully enabled categories that this activity belongs to and you could use that to drive your logic? I'm hesitant to add any highly specialized logic to the activity framework such as "can i disable this activity" because that's a policy decision and we don't want to code any more of that into the engine.
Mazen, do you think it's wise to offer this as API at this point? We havnt had time to review it properly and the only client at this point is a Workbench page. I would be much more comfortable pulling it out of WorkbenchActivityHelper and into an internal class for the time being.
when you say "this", which api in the class are you specifically refereing to? or are you talking about making the whole helper class internal? (Apologies Kim for not being quicker to use these apis). Im already using one of the apis and (will use more soon): WorkbenchActivityHelper.isEnabled( activityManager, category.getId());
I was only referring to the new methods I've added for 3.1 relating to category managment. I can never get rid of this class - API sticks around forever here. Which is exactly why I'm so concerned with keeping it when I've had 0 feedback regarding its usefullness and correctness.
Kim, I was in the middle of using getEnabledCategories(IActivityManager activityManager, String categoryId) and getDisabledCategories(IActivityManager activityManager, String categoryId) in the platform SDK. Intro happens to be a client that needs to poke around in the activity support, and this is why I agve you the feedback. Other clients will need them too. So to give you feedback about usefeullness, yes they are usefull. To give you the facts straight, I have used only the apis that I have mentioned so far. They seem to cover cases I can think off, because they are powerfull. They do all the logic that I gave you feedback on. You can make a decision about the other apis (eg: the apis manipulating activities). To give you feedback about correctness (eg: bugs), give me until tomorrow. First bug, in docs: for the getDisabledCategories(IActivityManager activityManager, String categoryId) the docs say: Return a list of category ids that will become implicity disabled if the given category becomes disabled. Note that the set returned by this set represents the delta of categories that would be enabled - if the category is already enabled then it is omitted. it should say: Note that the set returned by this set represents the delta of categories that would be disabled - if the category is already disabled then it is omitted.
and btw, what do you mean in the docs: Parameters: activityManager - the activity manager to test against * do I have to clone an activityManager before I use it?
My main concern is that the utility methods I've added are only useful for our (the SDKs) particular model for activities and categories. You could make the argument that a category is never enabled or disabled, but rather can be fully enabled, partially disabled, or totally disabled. You could also argue that our currently criteria for "enabled" is wrong. You could argue that if ANY contained activity is enabled then it too is enabled. That's the root of my apprehension. If you're already making use of them, however, I'll leave them be. To answer your question regarding cloning, no. You don't need to work on a clone of the activity manager. That parameter was added so that you COULD work on a clone. This was very useful for the preference page, for instance.
The new helper apis are good to clear any confusion. A category is enabled if all its activities are enabled. simple fact. Now, if you want to figure out the dependancies between categories, go to the wokbench helper class. I think this is a simple story.
Marking as fixed.
Verified that the API is in place in I20050330-0500
