nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

show my workareas

stimpy

What is the best way (via CSSDK interfaces) to replicate the function of URL command - viewmyworkareas.

The program will show up all the workareas that the user has write permission to.

Essentially, I would like to create a custom JSP page to list and all the workareas the user has access to.

Thanks,

Find more posts tagged with

Comments

Migrateduser

Stimpy,
The URL command is implemented using the CSSDK call:
CSBranch.getWorkareasForUser(CSUser owner, boolean recurse);
To get all the workareas a user has access too, you will have to call this once for the main branch in every archive (but if your installation is like most, there's a single archive - so call it recursively on the /default/main branch to get all the workareas for the user). If you have multiple archives, you should:
* Get all the stores using CSClient.getRoot().getStores(),
* Get the root branches for each store by calling getBranches() on each of the returned stores
* Call getWorkareasForUser(CSUser owner, boolean recurse on every branch.

Note that this will have adverse performance implications if you have a large number of branches and workareas, in which case you might want to call it non-recursively depending on which branch you're browsing - depending on your use case - or cache the results of the lookup so that you don't make the server call too often.

HTH,
Navneet

Migrateduser

Was there a good reason for not providing a recursive version/option of this method?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Actually, there is a recursive option - you can find all workareas for a user under a branch and all its sub-branches.
Due to the design of the server, you need to make the call once per main branch if you have multiple stores (which is not common) and hence multiple main branches. In such scenarios, though, you probably don't want to get all the workareas in every store, since muti-store backing stores typically have lots of branches and lots of workareas. Since the performance of this call is linear with the number of branches and workareas you have, doing a system-wide get-workareas-for-user is an expensive (set of) call(s), and you should be absolutely sure that you need to do it before making the call, and if you have the need to do it, you should cache the results so that you make the calls as infrequently as possible. (This is true if you have tons of branches and workareas in a single store too).

- Navneet

Migrateduser

Can you point to where in the Java Docs (or any documentation) where it describes how to call this method and have it run recursively?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Dave,
It's in the javadocs for CSBranch.
The getWorkareasForUser method takes two parameters, the first of which is a CSUser (the user for whose workareas you want to find) and the second of which is a boolean parameter called "recurse." Setting the latter to true will get you all workareas that user can access in the branch and all its sub-branches.
- Navneet

Migrateduser

That is correct - and I actually used that one to retrieve recursive workareas my user has access to. It was actually the getSubBranches() method in CSBranch that I would have liked to have had a recursive option for. This one specifically says you can't use it recursively. I'm curious why you didn't provide a recursive option for that method.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Dave,
We didn't realize it's something people would use, since a recursive branch walk is somewhat expensive, and typically that's not how you'd use it, because iusually administratorsprefer to organize their branches the way users would use them (ie if they want a flat view, typically, all the branches are at the same level, whereas if they want a hierarchical view, the branches are arranged accordingly).Doing things non-recursively seemed to make sense in both cases, since if you have a hierarchical view, you typically want to improve performance by getting data only when users want it (e.g. get children when a user tries to expand a tree node). Given this view, and because our internal users (ie the ContentCenter developers) didn't need it (since they wanted to get data only when they needed it, as in the latter case), and we went with those requirements.
If you think you need a recursive option, please file a feature request so that it can be addressed in an upcoming release.
I apologize if it's inconvenient, but it shouldn't be hard to write one yourself as a utility function in the interim.

Thanks,
Navneet

Migrateduser

This is not meant to be offensive, but you folks as developers really don't seem to think like customers very much. While recursive lookups may be expensive, that's hardly a reason not to include the option. Because branches can be many levels deep, it only makes sense that at some point (in my opinon this is a common thing) I'll need to do some recursive lookup of a branch. You guys should be concerned more with providing a robust set of tools and only try to figure out how we use (or want to use) the toolset by asking lots of us (customers). I still wonder how many customers you folks actually talk to when you say things like "usually administrators prefer". What your internal users do is maybe a good base idea for what might be good to put in there, but just because your internal users don't do something is a terrible reson not to include it. It's odd that you would put a recursive option in for workareas but not for branches. It's inconsistent. And please leave it to me to choose to use it or not use it if it's a performance hog. Just give me the option.

By the way, I did code it up myself, but I shouldn't have had to.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Dave,
I wasn't saying there's any harm having it - I simply stated why it didn't get done, and pointed out that our internal users didn't need it, so we didn't realize it was a deficiency.

Please keep in mind that given the rapid turnaround time in software development schedules (especially if you're rewriting things from the ground up), features that users who're driving the requirements don't want will typically not get done unless there appears to be a compelling reason for them. That's why we need your feedback - if you think you need a feature that doesn't exist, file a feature request so that we know it's something you want.

Please also realize that there are tons of things we "could" do, but each of them means more work (not just for development, but for docs and QA too), and we need to balance how many features we write, so that we can get a product out in time. Sometimes, we'll get that wrong, and need your help to identify things that we may have missed. So please keep the feature requests coming so that Product Management can have them on their radar, and make informed decisions about features and scheduling.

Thanks,
Navneet.

Migrateduser

Yes of course. I realize that it's easy for me to complain about what's not there. Although I don't really want to hear about how much effort it takes to update your docs - your docs need a lot of updating that never seems to get done. Feature requests are also a problem because you folks prioritize by how many companies ask for a specific feature. However you dont publish the list of open feature requests so that customers can attach their names to them. I know this is not your area, I just like to vent.

The one major flaw you and others often commit is saying that you did do some kind of customer poll for many things you talk about. Saying things like "most customers want this" or "many customers didn't want that". Until you poll my company, I will continue to be wary that you polled anyone. I find that a convenient phrase when you have no other backing for your claims. Whan I say "you" I mean Interwoven, not you personally.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

stimpy

Thanks for the reply Navneet

I got the showmyworkarea working in a scriptlet via iternations (3!)... probably not the most elegant code but working (havent tested it fully).

this is more of programming question than CSSDK, but how do you make this recursive rather than iterative? Which way is faster (least expensive)?

<%
for (int i=0; i<myStores.length; i++){
CSBranch myBranches[]= myStores.getBranches();
for(int j=0; j<myBranches.length; j++) {
CSWorkarea myWorkarea[]= myBranches.getWorkareasForUser(myUser, true);
for(int k=0; k<myWorkarea.length; k++) {
out.println(myWorkarea.getName() + "<br>");
}
}
}
%>

Migrateduser

Here's how I did it, keeping in mind I'm a Java novice and there is probably a better way. I use a subroutine to do the
iteration:

In main:

CSClient client = form.getClient();
root = new CSVPath(storeRoot);
CSBranch branch = client.getBranch(root,true);
branchlist = getRecursiveSubBranches(branch);
CSBranch[] branches = (CSBranch[]) branchlist.toArray(new CSBranch);

Subroutine:

public static ArrayList getRecursiveSubBranches(CSBranch branch) {
ArrayList list = new ArrayList();
CSBranch[] subs = null;
try {
subs = branch.getSubBranches();
for (int i=0; i<subs.length; i++) {
list.add(subs[ i ]);
list.addAll(getRecursiveSubBranches(subs[ i ]));
}
return list;
}
catch (CSException e) {
System.out.println("Failed Sub-Branch list");
}
return null;
}

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Dave,
I think he's trying to get workareas, not sub-branches, although this is pretty much how I'd have done getSubBranches recursively. Smiley Happy

- Navneet

Migrateduser

Stimpy,

Both your code and Dave's look good (although Dave's gets branches, not workareas, and is a different problem which actually lends itself better to recursion - read on).

To answer your question, while recursion is usually more elegant, iteration is normally cheaper than recursion since it avoids the overhead of method invocations, but can often be harder to implement(!) and read in scenarios that lend themselves easily to recursion. So both are suitable in different scenarios. (BTW, while there are three iterations, the second iteration will always be a single one (every store today has only one branch, the main branch). In this scenario, you don't need to recurse (in fact, you can't recurse, see the footnote); what you've done is exactly what I'd do too.

Here are some articles on recursion that you might find interesting:
http://www.msu.edu/user/pfaffben/writings/clc/recursion-vs-iteration.html (This one is about C, but most of it applies to any programming language).
http://www.cas.mcmaster.ca/~emil/se2c04/18recursion.pdf
http://math.scu.edu/~dsmolars/ma60/notesa3.html

Footnote:
why you can't recurse here:
Observe your iterations:
1. iterate over stores, getting their root branches
2. iterate over store branches, getting workareas for user
3 iterate over workareas recieved and print them

Yours is a classic iterative problem, and it doesn't lend itself to recursion. Since the iterations iterate over different types and perform different operations, there's no logical way to collapse them into a recursive function.

Typically, problems that lend themselves to recursion have the following features:
There exists a function F such that:
- F operates on T
- The execution of F generates additional objects of type T, which also need to be operated on by F
- There exists a termination condition where F will no longer generate additional objects of type T (this is often called the "end" or "unwind" condition).
More on this in the links above.

On the other hand, if we hadn't internally recursed sub-branches in the getWorkareasForUser() call, the problem have lent itself to recursion
since the operation
printRecursiveWorkareasForUser(CSBranch b)
would require you to
1. get all the workareas in branch b,
2. get all the sub-branches of b
3. if there are sub-branches Repeat 1 with all sub-branches

Here there's a function (printRecursiveWorkareasForUser) which operates on an object (CSBranch).
During its operation, it generates additional CSBranch objects which need to be operated on
If there are no sub-branches, you don't need to do any more.

The function would be something like
public void printRecursiveWorkareasForUser(CSBranch b) {
CSWorkarea[] waList=b.getWorkareasForUser(b); //assuming there was no recurse option
printWorkareas(waList); //assumed defined elsewhere to print the workareas.
CSBranch[] subBranches=b.getSubBranches();
if (subBranches!=null && subBranches.length!=0) {
printRecursiveWorkareasForUser();
}
}

HTH,
Navneet.

Migrateduser

Correction:
In the code in the footnote,
printRecursiveWorkareasForUser();
should be
printRecursiveWorkareasForUser(subBranches);

stimpy

thanks Dave for the code. I am sure it will be soon before I post "how to get em sub-braches!

Thanks

Stimp.