Home
TeamSite
Dynamic workflow initiation screen
System
TS 6.1 Win2K SP4
I need to modify the default configurable author submit workflow; the requirement is that there should be a list box on the workflow initiation screen and depending on the value in that list box, the rest of the screen should get painted. e.g. If the list box has values 'A' ,'B' and 'C' and if I select 'A' then another list box 'Level 1 Approvers' should get populated with values from a table and if I select 'B' then the same list box should get populated with values from another table.
So the question is, is it possible to repaint the screen and how to go about doing it?
Alternatively, is it possible to achieve this with 2 screens. i.e. on first screen I show only the list box and then on submit I display another screen with data from relevant tables.
I need to do all this BEFORE the job specification is prepared as the values selected in abovementioned screens will be used to generate the job spec.
TIA
Find more posts tagged with
Comments
Migrateduser
The ContentCenter workflow instantiation page does not include any explicit support for dynamic updates to the page; that is without a submit to the server. You could set up the WFT so that if there is a selection from the list box then the page would be redisplayed with additional input fields.
Alternatively, you could popup a second window to gather additional information, or write your own DHTML that updates the window.
Brinko Kobrin
Interwoven Staff Engineer
Migrateduser
You could set up the WFT so that if there is a selection from the list box then the page would be redisplayed with additional input fields. Alternatively, you could popup a second window to gather additional information, or write your own DHTML that updates the window.
How do you do either both of those things specifically in a WFT? I don't believe this is documented anywhere. Perhaps a Tech Note could be created that describes these options in detail. Certainly this is something that people might want to use.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
I have actually created an instantiation page on TS 5.5.2 that does the following:
2 select lists. When list one is modified, list 2 gets populated with new inputs. Specifically, I had a list of business units (departments) on list 1 and list 2 was for the selectable editors/approvers for those departments. But I didn't want the WF instantiator to have to go through a list of 500 users to find the right one.
The way I did it was to include quite a bit of javascript on the instantiation page. In order to pull this off, you need to be fairly familliar with the instantiation page itself and with Javascript. It actually took almost as long to create that instiation page as it did to complete the 30 task workflow.
I know this is still kind of vague, but at least you know it's possible. Brinko's suggestion about popping up another window (this would now be 3 levels of windows to complete the workflow) would also work, but it's messy for the end user.
- Jason
Adam Stoller
Another alternative would be to use a cgitask as the first task in the workflow, to capture the information and re-set various aspects of the instantiated workflow based on the information gathered. The advantage here is that the cgitask can work like a normal CGI program (with javascript, etc.) and it's more straight-forward than trying to embed that kind of code into the TAG_info() portion of the WFT instantiation screen.
One caveat (possibly the only one?) is that if part of the information you are gathering determines how many, or what kind of tasks should be generated when the WFT is instantiated - that information is best done on the original instantiation field -- or, using the aforementioned cgitask to spawn off nested workflows where that information can be passed in so as to do-the-right-thing when the sub-jobs are instantiated.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
One other problem that I've run into with a cgitask as the start task in a workflow is that when you are done entering the information, the TeamSite view does not automatically change to the Workflow (or ToDo) screen. This may seem like a small thing, but when inconsistent results happen during the same action (starting a workflow job) then the users tend to get confused. In this case the users think their inputs didn't get processed because nothing happens - the screen didn't change to the job view, so they are unsure their inputs were processed. That's been my experience anyway.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
Seriously Brinko - can you describe how to do the things you mentioned in your post? It's not really enough to say you can do something that's undocumented without explaining how.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
Seriously Dave, that's what "undocumented" means. I was only trying to give some advice regarding approaches that a developer could consider, not create a custom solution.
Brinko Kobrin
Interwoven Staff Engineer
Migrateduser
Evidently Interwoven is content to live with the crappy workflow documentation and anything that isn't covered in there is an exercise left to the reader? You offer the news that there's a way to do something a lot of people might want to do, but shrug off providing the details? What a huge help that is. It's things like this that make it hard for me to justify this product to my management and my customers. Your documentation is not nearly good enough to consider something undocumented as being insignificant.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
Dave,
Which part of Brinko's post are you interested in? The popping up of a 3rd browser window or the refreshing using DHTML? Both are fairly easy. You can include javascript in the HTML and label areas of the tags (among other places I'm sure). Don't be affraid of using OnChange events for your input fields on the instantiation page. Here's some examples:
html => "<select multiple size='8' onChange='handleUserChange();'>\n<option></option>\n</select>\n",
In this example, I've defined the handleUserChange() javascript function elsewhere, but if it was something simple I wanted to have happen, I could just put it in the onChange call rather than calling a function.
label => "</td></tr></table><script language='javascript' src='/iw/ChangeUser.js'></script>\n",
This is where I actually include the javascript source which contains most of the functions for the instantiation page.
Hope this clears up some of the mystery. <sarcasm>It seems obvious how much Brinko enjoys helping </sarcasm>. Lately I've mostly seen excuses and vague answers.
- Jason
Adam Stoller
There goes Smitty - attacking everything in site.
Brinko doesn't write the documentation (though I believe he was one of many people who should have been involved with reviewing it).
Brinko doesn't work as a consultant nor spend a lot of time creating workflows for customers other than Interwoven (if that)
All he indicated was that, technically, what was desired could be accomplished.
Yes - it would be nice if he could throw together a sample of such a thing, like he did with the sample externaltask and cgitask code he posted and documented - and maybe he'll do so again - but I hardly think that blasting him for responding about a technical feasibility without having fully documented self-help examples ready-to-go makes a lot of sense.
Smitty - Try to go a month thinking (or at least posting) constructively rather than destructively - if nothing else it will be good for your blood pressure ;-)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
Thanks so much for your advice. But no thanks. If it was just some guy saying that the particular problem could be solved, I wouldn't expect much else. But anyone representing Interwoven who says a problem can be solved and doesn't provide that little extra effort to say how that problem can be solved is not doing anyone any favors. Interwoven needs to go the extra mile and help us help ourselves. If that's not Brinko's job, then whose job is it? Get them on DevNet and post the answers. You're entitled to your opinions and you have a lot of them. I'm entitled to mine. Don't tell me how to post.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
nipper
>Brinko doesn't write the documentation (though I believe he was one of many people who should have been involved with reviewing it).
>Brinko doesn't work as a consultant nor spend a lot of time creating workflows for customers other than Interwoven (if that)
>All he indicated was that, technically, what was desired could be accomplished.
I agree it is not Brinko's job to make the documentation useful. But it is someone's job. No Brinko is not a consultant, in fact I do not
know if there are any/many of the old Interwoven consultants left. But the point remains that there is technology that IW provides &
there is a group of customers that ould like to use it. That was the hard part. The easy part is getting us the proper information
to do it. There has to be someone in IW that can document this information so we can use it.
Used to be SEs, Consultants and engineers wrote technotes. There are technotes of 1 paragraph on support. WTF is so hard about
documenting new functions/features so that they can be used.
>Yes - it would be nice if he could throw together a sample of such a thing, like he did with the sample externaltask and cgitask code he posted and >documented - and maybe he'll do so again - but I hardly think that blasting him for responding about a technical feasibility without having fully documented >self-help examples ready-to-go makes a lot of sense.
But we are the customer. We are correct. If we are not happy his product does not get used. Next time he is in the layoff list.
#FLAME off
Andy
Migrateduser
So really the only way to accomplish this kind of thing would be using JavaScript. I've heard rumplings around here not to use JavaScript in production code. Do you have an example in JavaScript that will change the elements of a listbox based on data entered in another field? I think rather than learn JavaScript it would be more robust to simply use a custom Java front end using the SDK and then build the job spec based on all the user inputs. Right now I use a CGI to build the job spec, but hopefully Interwoven will expose the Java libraries to help build a job spec. I would like to see how it's done in the 5.5.2 world as an example though. Thanks.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
Dave,
I personally think that Javascript is FAR more robust than Java. Especially when it's just simple javascript like onChange events. I wrote the code that would take 2 list boxes. When one is modified, it would read from LDAP and modify the second. This code works on IE, Netscape and MAC IE. If you stick to the simple JS (Javascript 1.1 or lower) and avoid complex stuff that's known to be incompatible between the browsers (like layers and the Document Object Model) then there should be no problem. On the other hand, Java is a much larger problem. Is your Java going to be running on SUN or MS JVM? Is the Java running on a MAC or a PC or Solaris? Although Java is
supposed
to behave the same way on all systems, it doesn't. There's a HUGE overhead to the JVM instances (talk to John about this. He really gets into the details of how the JVM is a resource hog.)
Next to Perl, Javascript is probably the most system independant language used on the web. BTW, a lot of people would argue that PERL shouldn't be used in an enterprise architecture, but we know better, right? One last point, there's Javascript ALL OVER the TeamSite interface. If not for Javascript, the entire interface would not function.
Example JS:
function handleUserChange()
{
countApprovers = document.iwwft_instantiator.approverUsers1.length;
var approverList = "";
var countOfSelected = 0;
for(i = 0; i < countApprovers; i++)
{
var approver = document.iwwft_instantiator.approverUsers1.options[i ].value;
var approverIsSelected = document.iwwft_instantiator.approverUsers1.options[i ].selected;
if (approverIsSelected)
{
if (countOfSelected > 0)
{
approverList = approverList + ":" + approver;
}
else
{
approverList = approver;
}
countOfSelected++;
}
}
document.iwwft_instantiator.hiddenUser1.value = approverList;
}
I'm not going to go into too many details about what this JS does, but it's basically called everytime the user select list on the instantiation page is changed. "approverUsers1" is the name of the select box. "hiddenUser1" is the name of a hidden field. The approverList ends up being a colon (
separated list of users.
- Jason
Migrateduser
Thanks Jason. I'll stare at this for a while and see if I can make sense of it. I appreciate the thoroughness of your help.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Johnny
wow there is alot of drama on this site.
Dave I think one of the methods mentioned might involve taking advantage of the required attribute.
You can change/add information to the screen by going back and forth checking required fields and repopulating them as needed, or adding new ones or removing them or whatever.
Basically using the validating methods, checking the values and processing a new set of TAG info fields.
As it's an indirect hack you may have to play around with the html styles etc to avoid seeing the error highlighting that comes up automatically.
Being a hack, I see why you may get a limited response by some people.
In my opinion I dont expect every iwov employee here to have their hat on the whole time feeling they have to provide official responses. I think that's one the great things of this place. I agree with the response by fish, I dont think he was saying to keep opinions to yourself, rather that the approach of attacking off the bat isnt really productive. I believe it only discourages such people to respond.
it's happened to me before (not by anyone in this post) and it really puts me off, i just couldnt understand the need for it.
anyway my five cents (no two cents in aust!)... doesnt happen very often
John Cuiuli
Migrateduser
I appreciate your response, John. The reason I got pissy about it is because originally I asked nicely for Brinko to provide the detail behind his original answer saying there was a solution. After I saw Brinko responding to other posts but not my request, I decided to ask again. Then Brinko came back with what I took as a brush off. If he had simply come back to my original request saying he didn't have time now but could possibly provide something later, that would have been fine. I think there is a responsibility on everyone at Interwoven to provide much needed help, especially in areas that are undocumented. Passing the buck is typical but who better to answer these types of questions than the engineers themselves? Anyway, I don't feel I attacked anyone right off the bat since I did originally ask nicely for the answer. It was only after that was ignored and then brushed off that I got pissy. I don't think what I originally asked for was out of place.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Johnny
Well I agree, it wasn't that fair to say it was off the bat.
Responding to a thread you participated in is common courtesy, but I guess sometimes people are put off and may keep from doing so.
Have a go with the required/validation method (though i dont know how the validation screens work in 6.x). It can be cleaner in most cases then client side scripting and you can take advantage of any server side modules or whatever. Only thing is that there may be more click throughs than a client side approach
It's tough keeping up with the responsibilities of living in society!
John Cuiuli
Migrateduser
What's done is done and I managed to irritate more people. All in a day's work. I just think complacency leads to people finding a different solution. The harder it is for us to make this product usable, the less likely our customers are to embrace it. I really do think the product itself is pretty solid. If only the documentation was solid as well, the engineers could simply point to it rather than leave things as an exercise to the reader.
I do apologize if I went off at the wrong people. But I have begged everyone I have ever met at Interwoven to make better docs. The workflow doc is still woefully inadequate. So who is the right person and what will it take to get it to happen? That's the million dollar question...
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
