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

Migrating custom menu items to TeamSite 6.0

I have a custom menu item application that I wish to use in TeamSite Version 6. It only needs to be available in Contact Center Professional UI.

I have modified the ui_custom.xml file in the customer toolkit and managed to display a new link on CC Pro but how do I reference my custom menu item application?

My custom menu item application requires to know where it was called from (the branch path). Will this information still be passed on?

Find more posts tagged with

Comments

If TeamSite 6 breaks old CMIs I am going to throw it out the window. You can't have an enterprise platform that requires so much customization if the platform shifts so significantly with each release - it indicates flaws in the base architecture.

I received a preliminary draft of the yet to be released UI Customization Guide for version 6.0. Supposedly this document is set for release in November. It should have been released with the product. Regardless, the draft version is 64 pages - granted many sections are still marked as TBD, including the section on how to add custom menu items - but 64 pages for the draft leads me to believe that this document will not be as detailed as it needs to be. After watching the webcast the other day about how to customize this UI, I have a feeling this document, like the workflow document, will be woefully inadequate. I hope I'm wrong, but based on the complexity I saw in the webcast, this document needs to be extremely detailed and complete. Because this will be a radically new way of configuring and customizing a product we have painstakingly administered in its old form, much unnecessary confusion will erupt unless this document is a fantastic one.

John - make sure the window is open before throwing TeamSite 6 out of it. Might as well minimize your costs as best you can. Smiley Happy

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

IWOV will be continuing to augment the new 6.0 documentation. We welcome specific feedback and input as to what additional tutorials, webcasts, and product documentation will help you, our developers be successful.

Please let us know. I am planning a more detailed UITK webcast series for January and February, but I need specifics on what you want. The first webcast was meant to give you an overview of what was possible.

If you missed it you can check out:
http://devnet.interwoven.com/site.fcgi/webcasts/index.html#webcast-23
for the recording.

Regards,

lissa

What struck me about the webcast was how complicated it all seems to make customizations - but I have a feeling that was due to how fast Darren was moving between the various files and screens - I was overwhelmed. I can't stress how important the documentation is going to be - not everyone can afford training - I don't even know if there's even a training class for customizing the UI anyway. Webcasts are great for overviews, but not for step-by-step instruction. Nothing is more important than the docs to get the proper info to the users. It needs to be precise and complete - step-by-step and easy to follow. Screen shots are immensely helpful in my experience. Perhaps online tutorials would be useful as well. It's so hard to say at this point having the product in my hands and not having the document I need to do what I want to do.

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

It wouldn't be so bad if the documentation included best practices in content management and best practices in Interwoven implementations in general. But it never does (another technique of increasing consulting revenue - Interwoven revenue mix is currently 40% license/60% services).

If the documentation actually documents functionality that will not work in subsequent versions or is so incomplete that we have to hack the system with show_env.cgi and such, leading the customer to invest significant development and training effort that will be wasted, I feel the vendor is not doing due diligence to the customer. Especially when Interwoven PSO has charged for delivery of customizations that won't work in subsequent releases.

Time for an open source replacement? Class action lawsuit?

Will Interwoven pull this post?

I am certain that upgrading to the new release will cause some headaches for those that have to test their previous customizations. I'm planning on taking the plunge within a few weeks. I would expect that supported customizations such as menus be supported in some way, but when it comes to my own hacks, yes, I'll have to deal with it. They weren't supported anyway.

I think Interwoven did the right thing and built a new UI from the ground up. Not duct taping it to support custom UI's that we all wanted. Sure it is complicated, but nothing about architecture of Teamsite is. As far as flaws in the architecture, it is a major enterprise software release. It's not like upgrading to Word XP from Word 2000. It takes a migration plan and testing -- bottom line.

I think the webcast appeared more complicated than it is only because there is so much you can do with the UI Toolkit and we only had an hour in this session.

If you have a copy of the work in progress UI Customization Guide I think that does a good job of getting you started and showing you what's where and how things work. If you don't just contact support and they can get you one. After that you should probably make sure to look at the UI reference files in the customer toolkit.

The ReadMe file that explains in more detail the five primary *.xml config files is located in the customer toolkit at:
<iw-home>/local/config/lib/content_center/customer/WEB-INF/conf/customer

In addition, you will find the reference files in the customer toolkit above to be very useful as you look at the UI you can relate what piece of the UI is covered by the item in the xml. The reference files for the css files are located in the customer toolkit at ...customer/ccpro/styles for examples has the custom.css and the ref_ccpro.css files.

What I showed in the webcast was the customer_samples customizations that are included in the toolkit. Using these samples go a long ways in showing you how to customize the UIs and I highly encourage you to experiment. Take a look at the OOB UIs, look at the reference XML and CSS files in the toolkit and make associations. Then configure the customer_sample customizations via the one line change in the toolkit.xml file as described in the UICG. Once the app rebuilds, look at the changes and trace those changes to the elements listed in the customer_sample XML files along with the changes to the CSS files.

I know there's more we can do on the documentation and it is being done but I do think you'll be able to figure out how things can be accomplished in the toolkit by using the UI Customization Guide and the reference and config files provided.

There is a training course for the UITK via our cyberschool:

http://interwoven.docenthost.com/docent/bin/docentisapi.dll/lms%2Cinterwoven.docenthost.com%2C2151/?CMD=LOGIN&file=login.jsm

Darren

The README file you referenced in your post is good stuff. This is exactly the kind of detail I hope makes it into the document. Thanks for the info, Darren.

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

I spoke too soon...this is extremely confusing. I am looking at the README file, which does a decent job of explaining the XML fields. But when I look at some of the reference XML files, say to see how the Actions menu in CCP is defined, I can't find the details. I see a bunch of links referencing other links. But I can't seem to find where the referenced links are defined. For instance, I'm simply trying to dig my way to the definition of the Actions->New Job drop down menu item, just to see how it is defined. I have found these lines in the ref_ccpro_ui_filesys.xml file:

<menu id="iw.ccpro.action.menu">
<link id="iw.ccpro.action_menu.new_job.link" refid="_iw.ccpro.new_job.link"/>

Well where do I find _iw.ccpro.new_job.link? Where do I find the meat of the definition of this menu item (label, href, windowFeatures, etc.)? Am I even on the right track? Seems like there are several levels of definitions scattered about in the directory structure. Or maybe my confusion is just making it harder than it is. Help...

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

I managed to just keep greping on these referenced links until I found one that actually defined something in a useful way...here's the path:

iw.ccpro.action_menu.new_job.link -> _iw.ccpro.new_job.link -> _iw.ccpro.instantiator_popup.link -> _iw.teamsite.common.daughter_popup_long.link

Then _iw.teamsite.common.daughter_popup_long.link finally defines something, but it's completely generic:

<link id="_iw.teamsite.common.daughter_popup_long.link" windowFeatures="width=600,height=600
,scrollbars=1,menubar=0,titlebar=0,resizable=1,status=1,center=true,dependent=false"/>

So where's the actual call to the instantiator? What am I missing in trying to follow the links to something useful?

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

Smitty, I have no clue & can offer no help. I only hope that IWOV gives you the 6.0 certification for free for all of the work you are going through.

you're asking a tough question, and i'm going to try to give you a carefull answer here. let me first explain that this is the first release of the UI toolkit, and we're trying to be carefull with what we expose in this release, and what we're going to keep to ourselves until we release version 2 in the winter.

so first of all, you've manged to find one of the more convoluted links in ccpro to start off with. but no matter. it's convoluted (or complex some might say), because it inherits behaviors from a long change of references. the chain is:
iw.ccpro.actioin_menu.new_job.link - the link instance that actually resides in the action menu.
_iw.ccpro.new_job.link - the reference that defines the new job behavoir. this actually defines the href, though we don't expose that in this release.
_iw.ccpro.instantiator_popup.link - this does nothing more than reference..
-iw.teamsite.common.daughter_popup_long.link - this defines windowFeatures that help keep all our instantiator windows looking consistent.

iw.ccpro.action_menu.new_job.link is contained within the iw.ccpro.action_menu (which is the drop down menu labeled actions in the ccpro content tab). so, the customization options are as follows:
a) you can now use the iwov-insert-before and the iwov-insert-after tags to insert your own, or one of our links into the list, using iw.ccpro.action_menu.new_job.link as the id attribute. for instance:
...
<iwov-insert-before id="iw.ccpro.action_menu.new_job.link">
<link id="nike.ccpro.action_menu.my_custom_link" href="..." .../>
</iwov-insert-before>
...
and this will insert my_custom_menu into the action_menu above new_job.

b) you can remove the menu item (if you don't want new_job there) using iwov-delete

c) what you're probably trying to do, which is to change the behavior of the new_job link. note that you will probably have to use the tags i mentioned before in order to accomplish this (to remove the exsiting new_job link, and replace it with your own), but what i believe we expose in this release is the capability to do the following: define your own link, inherit attributes of _iw.ccpro.new_job and override the particular parameters you want to change, as follows:
<link id="nike.ccpro.action_menu.new_job.link"
refid="_iw.ccpro.new_job.link"
label="Nike's New Job"
href="..."/>
now what this should do is: change the label on New Job, and override the href to what you have specified.

another clarification: you have noticed that the links we provide in the ref_ configs do not contain any hrefs. this is by design. in this release, we are not exposing the underlying implementation of our links, or the underlying urls they point to. (we do expose certain links along the lines of the 5.5 CCI urls, which i am sure you are familiar with). due to support reasons, we cannot yet share the literally hundreds of URLs that we internally use in the UIs. however, all of these links do have hrefs defined somewhere, and you are free to override them.

another important note, that i believe has already been mentioned: we will be providing a wrapper CGI which will allow you to use existing custom urls, and that should be available in the next few weeks. you will need to migrate your iw.cfg customizations to the new ui_configs, but your CGIs will continue to work as before. and now you can put them anywhere you want. and by the way, i urge you to start looking at implementing your new custom menu items using stuff like Servlets/JSPs and ContentServices which are really robust and easy to use.

i hope you are not more confused than before you posted.

ariel

I appreciate your very well written and detailed response. I think this only backs up my claim that fantastic documentation is essential for this new way of doing things to make sense to those of us who have done it the other way for so long.

My goal was actually not to modify the New Job functionality, but merely to try and see how it was defined. I was only trying to gather a real world example of what the README file contains in it. Apparently I picked a bad example, but due to the fact that you expose very little right now leads me to believe there are no good examples in the reference XML files. Again, this means that good documentation is essential because you can't really gather a full grasp of the information you really need to build your own new menu items, links, whatever based on these reference files. All they seem to do is reference things that we can't see. I'm fine with that, but it makes for some poor reference material, would you not agree?

As far as your suggestion to use Servlets/JSPs for my custom menu items, I regretfully do not know Java well enough to do that. I still would prefer to implement my Perl CGI custom menu items, and at the same time not have to recode my existing custom menu item scripts. I am hoping it is seemless to integrate my existing custom menu item scripts, however the documentation is incomplete in the draft version of the documentation as far as how to do this.

This whole exercise is solely to familiarize myself with the process of dealing with customizing whatever it is I can customize at this point, and at the very least get my custom menu scripts working in 6.0 exactly how they work now in 5.5.2.

Thanks again for your remarkably insightful reply - I am very appreciative that you took the time to explain things so clearly. That is genuinely helpful.

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

Dave,

The customization process is definetly geared towards Java and HTML coders. I think it's going to be adjustment to those who are use to Perl. I would definetly recommend reading up on servlets. They are definetly a lot of resource on Sun's site. Let me know if you want some recommendations.

Thanks,
Todd

Dev. Mgr., CCS and UITK

Surely you are not implying that my (and everyone else's) current CGI custom menu items will no longer be supported....

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

Surjit,

The parameter sent from the UI differs from WDP to CCP. We will provide an adapter within a few days that will reconstruct the old WDP parameters.

Will that solve your problem?

Thanks,
Todd

Dev. Mgr., CCS and UITK

Things like this are so disturbing. How can you not maintain backward compatibility with things like this? It's as if you folks just forgot that people are using a lot of custom menu scripts already in previous versions.

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

Hi Dave,

No Todd is NOT suggesting that we will not support CGI-based custom menu items. But what he is saying is that the UI Toolkit is geared towards Java Development. This was a conscious decision on our part and part of the Interwoven strategy going forward. J2EE is a robust, flexible framework that will enable customers to do much more than a scripting language like Perl.

However, we don't want to leave current customers behind so we are providing backwards compatibility for all of our customers who find themselves in Nike's situation with strong Perl knowledge but not too much J2EE knowledge.

Frankly, if you look at other enterprise apps and more specifically our competitors, they often come up with a new infrastructure and then drop support for old ways of doing things saying if you want to upgrade you need to do it this way, otherwise stay on your current version. FileNet is a perfect example of this. In their latest Pangon V8, they completely rearchitected the product and forced their customers to basically migrate all of their content from V7 repositories into V8 repositories and lose all of the work they had put into old implementations. Documentum is another example, when they released their V5 Webtop product, customers had to learn a completely new way to do UI related things.

This is just the evolutionary nature of software and I would appreciate it if you could cut us some slack. We are doing our best to provide backwards compatibility and respecting the real world needs of our customers. You can never move forward if you are bogged down by your past.

If you have any other issues with decisions that were made in IWOV 6 as far as product direction please send them to me and I will address them personally. In my opinion, having our developers defend technology decisions is not efficient use of their time. I'd rather have them be developing new features or working CGI wrapper for custom menu items that you need.

Thanks,
David Yun

Product Manager, Client Tools
dyun@interwoven.com

Edited by iwovdave on 10/24/03 06:05 PM (server time).

With all due respect, David, you better be ready for a lot more than this when more and more people start using this version. Moving forward with technological advancements is a wonderful thing and not unexpected. However, the lack of documentation and support to migrate from what is already a very complicated system is unacceptable. Little, if any, notice was given regarding what changes would be required in order to make our current functionality work in this new version. This version, especially since it is such a radical departure from all previous versions, should never have been released without thorough documentation. Whatever wrappers that are needed to support existing functionality should have already been there and well documented. People should not have to find something is wrong, come here and post their problem, and then be given the solution as an afterthought. Nobody is forcing anyone to stop progress and waste their time answering questions about why something isn't working the way it used to. If you didn't expect this kind of feedback, what exactly did you expect? We can all draw our own conclusions as to why so much time has to be spent doing this.

I will continue to use DevNet as it is a powerful tool to establish communication and get feedback from my peers out there. If you don't want to answer my posts here then don't. I wouldn't want to stop progress.

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

My general impression of 6.x is that it isn't about making things better for existing customers, it's about making the product more marketable to new customers. Interwoven isn't going to get any more revenue from Nike by changing the UI.

At this point I'd be happy enough if the product just worked the same as it did before. If I wanted to be a beta tester for 6.0 I would have signed up for the beta program. I don't have time to figure out why things that worked before aren't working now. And because I've already found 3 significant things that require me to change my currently working scripts (not new functionality, but simply transferring functionality that wasn't supposed to change by just upgrading to the new version), I feel compelled to have to test everything I have written to ensure it all works in this new version.

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

I think IW 6.0 will make things better for existing users of TeamSite. I think everyone would agree that the previous IW UI architecture prevented development of user-friendly, fit-for-purpose solutions for many companies. I think users and IW understand that most major implementations have made large and specific improvements to a TeamSite product deployment to make it work to their requirements (such is the nature of content managment) and total customisation of the UI will enable much greater value, removing some of the previous barriers for customers.

But its quite obvious that existing customers are going to have to look at IW 6.0 as a value judgement. Does the current and future value of IW6 outway the costs of migration including the development work, costs of re-training development/administration personnel, re-education of end-users to a new user interface all weighed up against the commercial risk IW have presented when in future they will no longer support the product? Id suggest that an upgrade project could be also used to re-assess your processes and other value-adds that can be incorporated into delivery and sold back into the business.

If the redevelopment of all custom CGIs is included in the migration cost, then so be it, as long as everyone is aware of the implications and can make a proper value judgement.

Its always a pain when vendors change product architecture effectively introducing risk into your architecture as you know that eventually you will be forced to upgrade to continue using the product, but they all do it. No one is forcing customers to do an immediate upgrade and time should be factored in to test everything involved with an ugrade.

This is my concern as well. No matter how good the new product is, if I have to re-learn, re-condigure, re-develop, re-test and re-train, it's really a new product, not a new version of an existing product.

well its a large piece of the product but at least you shouldn't have to re-do your workflow processes and content repository structure.

cold comfort maybe...