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

Diary of a perl junkie using the Java SDK

System

In my effort to create a Java app in TS6 to do the relatively simple task of:

o allowing a user to login to TeamSite
o display the branches that person has access to
o after choosing a branch, displaying a list of workflows the user can select from along with the list of modified files in the workarea for that branch
o instantiating the workflow passing it the selected information

I have compiled a short list of things it would have been nice to have available in the SDK to help accomplish these simple tasks and some other tasks I have in mind to add to this app.

o a method that mimics the behavior of availaible_templates.ipl as this was by far the most difficult thing to accomplish.
o a method to return a recursive list of branches - you can only get the list of top level branches in a store and given a branch you can get all its sub-branches, but there's no function to get the entire depth of branches in one shot - I had to build that method myself.
o a class to handle the email_map.cfg file and return user information (full name, email address) based on passing in the username. Also methods to add information to the email_map.cfg are needed.
o admin classes to handle administrative tasks like roles, various configuration options, etc.

I'll add more as I discover them. After pressing them, Interwoven finally admitted there is a small percentage of functionality actually exposed in the SDK. After using it, I find that you can do a lot of basic query type stuff for existing TeamSite assets, but to actually do anything useful, the SDK is pretty inadequate. It's been difficult to tie anyone at Interwoven down to provide a timeline for more functionality to become exposed. That disturbs me, as it could be months till I get more SDK help or it could be years.

Before I got started on this small app, I had no Java experience whatsoever and luckily I got a lot of help from a couple of our in-house Java developers. I came into this after listening to the IW marketing folks claimed that the entire 6.0 UI was built with the SDK. I really need to stop giving so much attention to the marketing folks. I still would be stuck at the available_templates logic if it wasn't for the idea of calling a CGI on the TeamSite server and having perl do that work for me. I cheated the same way with instantiating the workflow - I use a CGI instead of Java for that.

I have discovered that doing regex in Java is a joke coming from perl. Doing string manipulation in Java is annoying coming from perl. ****, doing just about anything seems a lot harder in Java coming from perl. Maybe I'll see the light in a few months of doing this. I think if more components were available in the SDK, life would be so much easier.

My advice to anyone who is considering building a custom UI with the CSSDK but isn't already very comfortable in Java is to figure out specifically what you want to do with your UI (design it up front) then read the CSSDK Java Docs carefully to see if you can do everything you need to do to accomplish your task. At first glance, there appears to be a lot of stuff in the SDK, but there's really not.

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

Find more posts tagged with

Comments

Migrateduser

I didn't want to reply to this post since it's basically a thinly-disguised rant, but seeing that it puts misleading "information" out there, I suppose I must.
First off, for those of you who haven't read the thread "Which method mimics the new Job Menu Item," I will summarize the author's initial problem that sparked this rant:
* The author wants to use CSSDK to access the available_templates.cfg file and can't and he doesn't like it.

Wait, I hear you say, why can't we do that?
Here's why: the available_templates.cfg file is a configuration file, not an API - it's part of the WFT system of instantiating jobs and controls the jobs presented by the instantiator GUI - i.e - no instantiator GUI, no point to the available_templates.cfg file. While still supported, the WFT system uses a mixture of HTML perl scripts to present a barebones UI for instantiating a job. This UI gathers input for fields required to create an XML job specification, and then creates the job specification, resulting in the job being instantiated.
What does this mean? This means the WFT system is not an API. It's more of a product by itself, where the UI and code are one black box, and therefore inseparable. Does this mean you can't create jobs using CSSDK? No, it doesn't - there are APIs in CSSDK to create and manipulate jobs and tasks. What this doesn mean is you can't use the WFT system to do it. If you do want to use the WFT system, the UI toolkit provides the functionality to do it - you just can't use the API since the API by definition has no UI code, and the UI by definition is not an API.

The UI Toolkit v/s the ContentServices SDK API

The UI Toolkit
In general, any user interface, properly designed, consists of components. The UI Toolkit's first release attempts to go beyond what most normal UIs do by providing URLs to access prepackaged UI functionality, including WFT instantiation. This shouldn't be a problem, given that WFT is basically a means to put a UI over XML job creation. Another case where functionality is exposed through the UI toolkit, not the API, is Templating. Again, templating is fundamentally a UI product (although, admittedly, a few actions could be extracted and an API put around them -e.g. template generation - and if you want that, I encourage you to submit a feature request to Interwoven).
Bottom line - even though most UIs don't do it, Interwoven's UIs provide access to componentized sections of the UI through URLs so that a developer can use these pre-packaged UI components to achieve some tasks.

The ContentServices SDK 2.0 API
So what is an API or SDK? An API or SDK is a means to programmatically manipulate objects, normally in a server. The API resides between the user interface and the server. The ContentServices SDK exposes *every* feature of the TeamSite server, and is the same SDK that was used to write the UI. The UI, as is often the case, does add some additional logic above the SDK, but it's nothing that can't be replicated - however, every single call that accesses the TeamSite server goes through ContentServices.
So, in summary, CSSDK does provide means to access every single *SERVER* feature of TeamSite. Some additional *CLIENT* functions are made available through the UI Toolkit, (and hopefully, this list of functions will grow with time and feedback). If you find a TeamSite *server* feature that is not exposed through CSSDK, please do file a feature request - thus far none have been filed. If you want some APIs for templating to be exposed through CSSDK, please file a feature request for that as well.

However, I do agree with the author on one point - it's always good idea to design your code up front, prototype little pieces to make sure you know how the cogs work, and only then start putting together your product. It's excellent advice, that's not limited to developing with TeamSite, but should be followed no matter what the development task.

Finally, I quote from the post:
After pressing them, Interwoven finally admitted there is a small percentage of functionality actually exposed in the SDK. After using it, I find that you can do a lot of basic query type stuff for existing TeamSite assets, but to actually do anything useful, the SDK is pretty inadequate. It's been difficult to tie anyone at Interwoven down to provide a timeline for more functionality to become exposed. That disturbs me, as it could be months till I get more SDK help or it could be years.
That's not a distortion of reality - it's just blatantly false. Nobody at Interwoven has said that, and nobody will - because it's just plain untrue. The UI Toolkit will continue to evolve with feedback, however, all server functionality is, and will continue to be, exposed through the CSSDK.

Thanks for reading.

- Navneet

scr_exstream16.2.png

Migrateduser

So you are trying to make it seem like the issues I had were my incompetance rather than the toolset being inadequate. And your tone is argumentative, so evidently I hit a nerve. Whoops.

I stand by my description of the pain I went through to get the most simplest of apps working with the SDK. You can call the workflow WFT interface not a UI or something different than the rest of the toolset, but why? To me and everyone else that uses TeamSite, workflow and the UI's that accompany workflow as we know it are part of the stinkin' UI. You can claim they are not, but really they are because they pop up info to the user and the user interfaces with that stuff....hence they are UI's. While I agree that I don't want to use a WFT via the SDK, I do want to utilize the XML available_templates.cfg data to determine which workflows are available for a particular user in a particular area - why wouldn't you have included something similar for us to use in a custom app? Would you really require us to build our own process to figure this stuff out when you have one already there? I believe this was a blunder on your part. You can disagree all you want, but without it you have left out some major functionality.

Honest to ****, I could not care less how you define things semantically. Your post is more confusing than anything else - it seems like one big excuse for not living up to the statement that "the entire TeamSite UI was built with the SDK", which is true or false depending on how you define UI. I guess that's sort of the same as how Clinton defines sexual relations. I call it false even after your desperate attempt to claim otherwise. The folks at Interwoven had always said all UI functionality can be done through the SDK....never did they limit that statement to all server functionality until you just did in your post.

The bottom line is I had to use means other than the SDK to mimic the simplest TeamSite UI behavior. The workflow process is hardly covered at all. And without being able to create and choose and execute workflow in the same fashion as I can today, I stand behind the statement that the limited SDK is inadequate in that regard.

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

Migrateduser

I didn't make any statement about incompetence, inferred or otherwise - I was just stating facts and making sure that the correct information gets out there. I'm sorry if you felt I was, that certainly wasn't my intent.

Also - I did say that the WFTs are purely UI - I didn't contradict you there - in fact that's thre reason it's not in CSSDK! CSSDK is not UI! the UI Toolkit is UI.

Actually - the statement was "All UI functionality was built using the SDK" - which means no internal APIs. That is completely true. While I understand that you want to use the available_templates.cfg file because it is a means that exists in the backend that does something you want it to do, exposing it without exposing WFTs, as I pointed out to you earlier, would be confusing - there's no point exposing an API that lets you read a configuration file, when the stuff the configuration file controls is not in the API. I stand by that statement, and if I was asked today to choose whether or not to expose available_templates.cfg, I wouldn't - not because it's hard to do, but because it's the wrong thing to do. And I stand by that statement.

Also, you didn't have to build the functionality using something other than CSSDK - you went down that road because you had your heart set on using WFTs and available_templates.cfg. I did outline how you could build the same functionality using just CSSDK, but you thought it was too much work and preferred to go down the alternate route (a method, BTW, which was suggested by one of the folks on the UI team - it's what they had to do to integrate WFT code into ContentCenter) - that was your decision, not something that was forced on you by an inadequacy in the CSSDK.

While it's your decision whether or not you're going to use the UI Toolkit supplied to instantiate jobs, and I certainly see the reasons why you might want to do it, please don't expect to use bits and pieces of the code that is part of the UI to build your own UI. You can have one or the other. If you want to use the UI ... voila! available_templates.cfg and the WFT system are at your feet - use the UI Toolkit. If you don't, use the native API and build your logic on top of it. If you're asking for bits and pieces of the UI code to make your life easier, you're basically asking us to give you access the UI code, not to extend the API it's built on.

FYI : when experimenting with cross-platform CSSDK, I built a fairly generic Workflow instantiation framework using CSSDK in .NET, based on XML and XSLT. The exercise only took me a couple of days - it's really not that hard. And it's more modular - you can separate the UI component of workflow instantation from the job specification and permissioning, and change them independently. And, like I said, it only took me a couple of days. Starting from scratch in .NET with the bare-bones SOAP-based CSSDK, with nothing but the shipped workflow and CSSDK documentation as a reference. Sorry I can't share that code, it's not supportable as it wasn't built to be - it was just a prototype to make sure CSSDK could do everything it needed to without WFT - and it can.

- Navneet

Edited by njoneja on 04/26/04 12:21 PM (server time).

Migrateduser

Actually - the statement was "All UI functionality was built using the SDK" - which means no internal APIs. That is completely true.
You're kidding me with this, right? You're gleefully going to claim victory with this argument and stand by the claim that this is not misleading to the vast majority of your customers? Congratulations.

you went down that road because you had your heart set on using WFTs and available_templates.cfg
Actually if you were paying attention, I didn't use WFT's at all. All I wanted was a function that would return to me an array of workflow names based on the user, the area and role. Then I could display that list however I chose. I didn't want to use the TeamSite pop-up at all - just a way to retrieve a list of workflow names. That is absolutely do-able for you right now in the SDK but you didn't do it. Shame on you.

And because I have to use available_templates.ipl, which resides on the TeamSIte server, I have to call a CGI to retrieve that list. You should absolutely provide a hook into available_templates.cfg - not so I can run a WFT or pop up the TS window - but to return a list of workflow names. That would be huge. If you don't see why that would be good, you need to really start thinking like a customer instead of a developer of an app.

The ability to create a job spec based on user inputs is much easier for me to do in CGI than in Java. It could very well be that I could do this in Java just as well, but you didn't supply me with the hooks to do so in your SDK and I don't have the time to figure it out in Java. I can simply call a CGI that does it in perl so easily, based on the inputs the user entered in my Java UI, and then instantiates the job and returns useful information to my Java app. You're supposed to make using TeamSIte's abilities easier for me. Until you do, I'll be forced to go down the easiest path I can find to get my job done. Right now, that isn't with the SDK alone. It's inadequate for my needs.

My original post was meant to prepare anyone in my same shoes - with limited Java expertise and a whole lot of perl expertise and TeamSite experience creating workflow - for thinking that the SDK provided by Interwoven was going to be this all encompassing tool we could use to convert over to home grown UI's. It's simply not good enough yet for people like me. You left out stuff that is integral to what many people use TeamSite for every day. You claim it can all be done, but good friggin' luck if you want to use workflow. I made it work, but not with the SDK being able to do everything. It was a diary of my experience. I don't blame you for not being happy that it wasn't easy as pie to do what you advertised it would do. Maybe you should spend your energy making it better than arguing semantics with me as to why it's not better.

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

Migrateduser

I notice you edited your post after I already responded to it. Nicely done. I must ask you some questions based on your thinking that the logic in available_templates is not needed in the SDK (or wherever you think it would go based on whether it's server or client functionality - I'm too confused to figure that part out). How do you suppose that people are to create job specs if they want to create workflow using a Java based UI using the SDK? You certainly didn't provide any methods anywhere to create a usertask, an externaltask, etc. How do you also suppose, assuming I figured out a way to create my job specs (aka workflows), I would display the available workflows to my users in my Java UI written with the SDK? Hmmm...guess I'd have to custom build all that functionality, eh? Is that considered server or client finctionality? If it's server functionality, I should be able to do it in the SDK, based on your winded explanation. If it's client fuinctionality I should be able to do it in the UI Toolkit, based on more of your explanation. This is basic TeamSite stuff. I don't care what type of functionality you call it. Just make it so I can do it seamlessly. An SDK without hooks into standard workflow abilities is a substandard SDK. You provide methods to manipulate existing tasks in a running workflow. But you didn't provide methods to create a job spec containing those tasks. Isn't that putting the cart in front of the horse?

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

Migrateduser

> How do you suppose that people are to create job specs if they want to create workflow using a Java based UI using the SDK? You certainly didn't provide any methods anywhere to create a usertask, an externaltask, etc.

On one project I wrote a Java package that provided classes for creating the various tasks (not all Interwoven functionality was supported) and another for creating workflows from sequences of tasks and representing each as XML - let me know if you are interested and I can put you in touch with the current code owner. Workflow development is much easier in an object-oriented environment with syntax completion. Of course writing the foundation classes shouldn't be all customers' responsibility.

Actually this brings up an interesting security issue; if any user can create a job from any XML using OpenAPI if they have access to the server, couldn't they create a job with a start task that would run any system command as any user...oh wait, we're not supposed to think/talk about the (in)security of this product.

Migrateduser

Your suggestion that we have a nicer way to build job specification XMLs through CSSDK is an excellent one. Please submit it as a feature request so that it gets routed through the appropriate channels.
I didn't edit my post after you replied to it (please check the timestamp) - I edited it almost immediately after I posted it. Sorry if that caused you confusion.

Thanks,
Navneet.

Migrateduser

Although I'm sure what you created is good stuff, I think I would rather wait until Interwoven exposes something similar, if only to maintain compatibility and supportability in the future. I have something I built myself which is not really following the OO rules, but does the trick and is easily expandable. It's just not in Java. I really think this would be a natural extension to the SDK. Even if I had your code in Java I'd still require the available_templates logic exposed as well. Did you code that up as well?

I do appreciate your offer.

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

Migrateduser

> I'd still require the available_templates logic exposed as well. Did you code that up as well?

Heck no I hate that thing almost as much as templating.cfg - it doesn't have anything like the full compliment of workflow control logic you would see in an enterprise-class workflow engine. There was just one .wft triggered on every TeamSite action that would write a hidden form that would automatically post to a custom JSP that had the business logic to determine and invoke TeamSite workflow.

Migrateduser

OK now I think we're getting somewhere. And I apologize if I was wrong about when you edited your post. That was just an admittedly snotty remark on my part. So if you agree that having methods to create job specs in the SDK is a great idea, wouldn't you also agree that having some kind of ability to filter which job specs are available to build based on the user, role and area is a great idea as well?

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

Migrateduser

Yeah that's the thing. I figured as long as I have to call a CGI on the TeamSite server to run available_templates.ipl to return the list of available job specs I can build, I might as well use perl's exceptional string capabilities to make my own WFT type thing and just pass another CGI the user's inputs and then plug them into the XML, then instantiate it. Piece of cake. I'm sure it can be done in Java, but since I was already cheating, why not cheat really good?

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

Migrateduser

If there is a way to build job-spec "templates" (ie template objects) in CSSDK using an OO paradigm and then instantiate them, it does feel like a means to save these objects as templates using the SDK and then to allow permissioning of those objects based on various parameters would be a natural extension.
Please be sure to include this in your feature request as well, so that it can be taken into account when the appropriate team determines future product features and priorities.

- Navneet.

Migrateduser

Yay! We agree. Thank you for listening.

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