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; } } }

Which method mimics the New Job menu item?

Which SDK Class/Method mimics the results of selecting New Job from the Actions menu in TS 6.0? I need to present a list of allowable workflows for a user using the same criteria as what's in the available_templates.cfg file. I assume there must be a method somewhere that returns a list of allowable workflow templates a user can execute based on which branch they are working in. Can someone point me to this method?

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

Find more posts tagged with

Comments

Dave - Unfortunately, CSSDK does not provide that functionality, so the UIs are using an internal (unpublished) method for doing this. Did you need to build your own UI for it or can you use the "/newjob" CCI URL instead? That will provide the same functionality as the New Job menu item.

Also, if you are planning on creating jobs using CSSDK, it only provides a way to create workflows using job specs, not WFTs. Therefore, if you want users to be able to select a WFT and create a job from a WFT, you will need to use the CCI URL.

-Pam

Edited by PJoneja on 02/02/04 01:48 PM (server time).

That figures. I guess that disproves the statement by Interwoven that they built the entire 6.0 UI using the SDK. But anyway, what I want to be able to do is use a customized Java front-end to get people logged in and display a list of available workflows they can use based on whatever prompts I ask them for. I realize that I would need to modify my WFT files so that I would get my inputs from the Java script, embed the info to create a job spec, then execute the job spec to kick off the job. But that's the beauty of it - it's a much easier thing to maintain than WFT files. I'd just like to provide the same list that would get displayed if the user used Action->New Job. Why on earth would that method be kept private? Why not give that to us to use? What's the harm?

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

Did you need to build your own UI for it or can you use the "/newjob" CCI URL instead? That will provide the same functionality as the New Job menu item.

I would assume that using the CCI URL would pop up the standard TeamSite window that displays the list of available workflow templates? If that's the case, then no that wouldn't work. We are wrapping all of our windows in a very specific company look and feel. Popping up a TeamSite window in the middle of our app would be against what we're going for here.

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

Dave Smith wrote: I guess that disproves the statement by Interwoven that they built the entire 6.0 UI using the SDK.

Well, that was the intention, but this must have slipped through. I suggest that you have support file this as a feature request.

Have you looked at available_templates.ipl? I believe that it will do what you want, although it's not as simple as calling a CS method.

-Pam

You know Pam, saying "that was the intention" and then brushing it off is just not acceptable. Interwoven made a very big deal touting how they built this UI using only the SDK. That implied we could take any piece of it and duplicate the functionality in our own custom UI pretty easily. I find it insulting that Interwoven would just say "oh well, guess you'll have to find another way" after advertising such a claim. We've spent a lot of time and effort in deciding to build our own custom UI, and then after we've invested all this time we find out that the SDK is missing a standard UI piece. What else is missing? What else did Interwoven decide to keep private? Interwoven seems to be under the illusion that they can get away with these comments and brush them aside when they are proven to be false. It's not right.

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

Dave,
CSSDK allows you to create jobs from XML job specifications; there is currently no API to get WFTs, internal or external; the use of WFTs in ContentCenter, as I understand it, merely wraps the old WFT CGIs.
Furthermore, when you instantiate a job using a WFT, the WFT embeds perl code which translates into CGIs and external tasks; WFTs are a combination of UI logic, external tasks, and Workflow specifications. If your goal is to not use an Interwoven UI at all, then WFTs will not suit your goals.
What you want to do instead is to create XML job specfications and then use CSSDK to create the jobs. You can do this using XML and XSL, among many other means. Which means your workflow templates would be pure XML, not WFT based.

To summarize: WFTs are not pure logic, they're a mix of UI and logic, which is why it is impossible to put an API around them. Hence, CSSDK exposes means to create jobs using XML job specifications, which you can use.

So, yes, it is still possible for you to do anything you want without going through the UI or CCI URLs, however, you can't reuse WFTs to do so, since WFTs are implicitly tied to CGI-based UI logic, form validation, etc.

Hope that answers your question.
- Navneet.

I'm pretty aware of how WFTs work. You don't understand what I'm looking for here. I want the allowable workflows that a person can run based on who they are and where they are - essentially what gets produced when you click Action->New Job. From there they can choose the selection they want and then I can do whatever I choose with that information. I envision changing all my WFTs into basically templated XML files and plugging in values where appropriate after prompting the user for information at that point, producing a job spec. Then I can execute the job spec to kick off the job. I am not looking to use the WFTs, only to list them since the New Job functionality should already do for me based on how I have available_templates.cfg set up. Since Interwoven claimed they built the entire 6.0 UI from the SDK, I assumed that there would be a method available to do just that. I should have known what happens when I assume....

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

Dave,
If you're planning to use pure templated XML, you're on the right track. In that case it seems what you really want do is to reuse the information in available_templates without actually using the WFT mechanism, potentially in order to reuse the "permissions" mechanism provided by available_templates.

Instead of doing that, why don't you make a clean break from WFTs altogether? Use the templated XML that you're planning on using, and create a simple permissions config file that you use (and now you no longer need to use WFTs or available_templates) in order to determine which user can use which workflows. You could even generate this file for the first time by doing an XSLT transform on your existing available_templates.

And that's the crux of the matter: Since CSSDK cannot put an API around WFTs, it didn't make sense to release an API that lists WFTs that you can't do anything with, especially because then you're exposing the concept of a WFT in an API that can't do anything with WFTs, which makes the API inconsistent.

While our UIs have been built from scratch using only public APIs, they do need to use WFTs to instantiate workflows, for backwards compatibility - and that's what drives the new job menu.

- Navneet.

Edited by njoneja on 02/03/04 03:49 PM (server time).

Well it appears that's the road I'm going to have to go down. I am just disappointed that some of the UI capabilities don't exist in the SDK. It makes me curious how many other UI components aren't available in the SDK. It is not fun going into a mine field blind. It would have been nice knowing specifically which UI components are not provided before we do a bunch of development only to get stuck when we find something isn't there and we have to scramble to build it ourselves. Our Java resources are extremely limited here, and those that we have know little about TeamSite. We need to be able to count on the tools provided being complete and well documented.

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

Dave -

I'm sure it is frustrating to find these limitations in our SDK, and I didn't mean to belittle your problem. It was a bad choice of words.

As Navneet mentioned, the workflow instantiation piece of ContentCenter is implemented with wrappers around the old workflow CGIs. The "internal method" that our UIs use to get the list of available WFTs is just a wrapper around available_templates.ipl, and ContentCenter still uses the same old CGI to actually instantiate the jobs (it just looks new because it now supports stylesheets).

Although it's not the solution you were hoping for, you could do the same.

-Pam

No I think that really is unacceptable.

I'm going to revisit this again, now that I'm at the point where I need to "mimic" the behavior of the UI that displays the list of workflows that are available to me based on the available_templates.cfg file. I am simply not satisfied with any of the answers given previously in this thread. I believe that regardless of whether it makes sense to use WFTs via a Java interface, it certainly makes sense that I would still want to filter out which workflows I make available based on the exact same criteria available_templates.cfg gives me. I don't want to reinvent the wheel, and I shouldn't have to. Interwoven should provide something in the SDK that allows me to gather that list of workflows based on the same crtiteria TeamSIte uses to filter using available_templates.cfg. To tell me I need to create some wrapper of my own is absolutely against everything Interwoven claimed this SDK represents. If it's in the standard TeamSite UI, it should be in the SDK. Using the excuses that it slipped through the cracks, or that Interwoven didn't think it would be useful because it doesn't make sense that people would use WFTs is ridiculous. It's easy to make a job spec from user inputs not using a WFT, but I still need the functionality to display only the workflow options that I defined in my available_templates.cfg. Since Interwoven has managed to do this for the CCP UI, why don't you just give me your code so I don't have to figure it out for myself?

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

Let me make this even simpler. All I would request would be one simple method that I pass in the appropriate criteria to (user, role, branch/workarea path, etc) and the method returns me a list of workflow names. This could simply be the prefix of the WFT file name. Then I can do whatever I want with that list of workflow names. That's all I'm looking for. Just give me a hook into the available_templates.cfg file so I don't have to reinvent that logic. Is that not a reasonable request?

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

Screenshot1.jpg

There are no APIs for getting workflows or templates. Launchpad is still somewhat CGI based and doesn't use CS for everything. That's the extent of the UI that doesn't use CS that I'm aware of.

Our resources are limited too, so we don't solve every problem at once some times.

Thanks,
Todd

Dev. Mgr., CCS and UITK

I don't really care what the specifics are. I think it's a shortcoming that there is no way to parse the available_tenmplates.cfg file to retrieve that information. I haven't heard anything that implies you are going to stop using available_templates.cfg to determine valid workflows for users, so you should have something in there we can use to mimic the behavior of the UI in our own apps.

Our resources are limited too, so we don't solve every problem at once some times.
Unacceptable excuse. It was more than one Interwoven Product Manager who claimed that the entire CCS/CCP UIs were developed with the SDK. I didn't make that up. You don't get to make excuses when you made a claim like that. Make it a bug and fix it if you still stand behind that claim or tell us the truth about which specific UI components are not available in the SDK.

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

>> I don't really care what the specifics are.

You said "It makes me curious how many other UI components aren't available in the SDK". I answered your question.

>> I think it's a shortcoming

I agree

>> Unacceptable excuse.

My statement wasn't an excuse, it was a fact.

You have the information you requested. I will not engage in a debate about what our PM or marketing department claims.

Dev. Mgr., CCS and UITK

I think you could put a symlink from IWHOME/httpd/iw/available_templates.cfg to the real file, then have your custom code pull & parse that XML. Not really acceptable from a customer perspective but a workaround if you really need this functionality.

> I will not engage in a debate about what our PM or marketing department claims.

That is certainly good policy as engineering and marketing have quite different impressions of what the products are, do and how they were built.

>> I don't really care what the specifics are.

You said "It makes me curious how many other UI components aren't available in the SDK". I answered your question.

You're right - I didn't pay enough attention to what you were trying to tell me. My apologies.

Unfortunately, you as an engineer are tied to those marketing claims by the simple fact that you work for the same company. I as a customer am given expectations based on anything your marketing department tells me. When those expectations are not met, someone has to take responsibility and make it right, one way or another. I realize you are not the person who might have made those statements, but you are a representative of the people who made those statements. If you are not willing to discuss it I would like someone, perhaps one of the people who did make the statement, to do the right thing and either fess up or make the product do what they claimed it would do. I still haven't heard anyone say that the thing I'm looking for will be put in the SDK. And if it won't be put in the SDK, I'd like to know why not based on the promise that the SDK should contain everything needed to build the TeamSite UI.

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

I'm not really following what you're saying, John. In your statement, what is the "real file"?

The reason I'm harping on this so much is because I'm trying to learn Java from knowing nothing about Java at the same time I'm building a real world production app in Java using the SDK and an IDE I am just learning at the same time while conforming to the STRUTS framework, which I am also just learning from scratch. Building the interface to the available_templates.cfg file in Java is just another thing I don't have time to do right now. Nor should I have to, since it is already a part of the TeamSite UI, and therefore should already be in the SDK for me to use. I am tired of being misled by marketing folks - it's time to say "enough is enough" and force some people to take responsibility for empty promises. It's a struggle enough to convince people here that TeamSIte is good for them, and I have been bitten too many times by passing on promises to potential customers based on things Interwoven marketing has promised but not delivered.

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

There's something so wrong about that.

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

It is your perception they are out of synch but not mine. CC is built on top of CS, however for 99% of the CC application we do not expose the logic as an API. For example do you see APIs to add new wizards? Or APIs for using our JSP tags? You don't because we don't expose these. We do expose URLs and an XML customization framework and a few other smaller items.

The code to read available_templates.cfg is entirely in the CC application layer, just like the logic to display a wizard is entirely written in the CC application. It is not a hidden CS API. PMs statement has to do with the CC application utilizing CS, not that we expose all of the CC application as an API.

We chose not to expose that code because we're not ready to. For us to expose a piece of code it involves design reviews, testing and documentation. Therefore not everything we have developed is exposed immediately and we make choices about what's highest priority.

The bottom line is:
- I agree this functionality as API would be useful (as well as templating APIs)
- The company is investigating when we can do this
- We can not provide a commit date when we can do this

Thanks,
Todd

Dev. Mgr., CCS and UITK

Now that's an explanation. Thanks for that. As far as your first paragraph goes, I don't really know anything about wizards or your specific JSP tags - I don't have any need to use wizards in my app and we use the STRUTS JSP tags. I am not Java-savvy enough to comment on those kinds of details.

Your second paragraph is interesting. I heard the same argument about the UI Toolkit - that only a small portion is exposed and we will have to wait for more. But I do not recall anyone saying that about the SDK until you just did now. I think Interwoven should have never made the claim they did at last Focus Group and should not make it again. The broad claim that the entire UI was written with the SDK is clearly false. Somebody should have clued marketing in on that blunder.

I will accept, based on your explanation, that the available_templates lookup is coming down the road, as well as whatever else I might find in my journey to develop a simple app for my customers.

I really think that marketing is doing a real disservice to us customers by making claims that engineering clearly can't live up to. I pass this information along to my customers, and now I have to go back and tell them it wasn't true. If this happens enough times, it will be hard for me to sell this product to our customers.

Thanks again for the explanation.

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

I should clarify: there is no technical difference between the UITK and the CC application. They are the same, that's why the story sounds the same.

The CC application is constructed of modules, toolkits, layers, whatever you want to call it. We have basic modules for create UI applications (similar to Struts). Then on top of that we've constructed a module for basic Teamsite UI functionality. On top of that we have several modules, CCS and CCP being two of them. Additionally we have a module for common templating UI logic.

The UITK exposes 1% of the functionality in many of these modules. The code to read available_templates.cfg lives in one of these modules, and the code to read templating.cfg lives in one of these modules. Over time we'd like to increase that 1% to a higher number.

We'll get there, but I can't say when yet.

Dev. Mgr., CCS and UITK