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

CMI: CGI or JSP?

System

I may have to write a custom menu item. Currently the server is 5.5.2 and there are many custom Perl modules, so Perl is the easy route. I could also go JSP (with a hidden HTML form written from Perl to repost the form data to the JSP). The only parameter I need is path_0, the selected file (I would also like path_1 to ensure they have not selected more than one file).

My question is, if I write this in CGI/Perl today, how much effort would be required to port it to 6.1 tomorrow? Should I just write it in JSP today even if that means a significantly increased development effort?

How can I write my CMI so that it works in 5.5.2 *and* 6.x? Are there instructions for this somewhere, or a list of issues for rewriting CGI CMIs for 6.x?

Find more posts tagged with

Comments

Migrateduser

You can write custom menu item scripts in perl for both 5.x and 6.x versions. Interwoven would be making a lot of people angry if they stopped supporting perl as its scripting language given many of us have large libraries of scripts written in perl.

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

Migrateduser

Check out Tech Note 50541. This explains that the parameters passed to custom menu items in 5.x (WebDesk/WebDeskPro) and 6.x (ContentCenter) are completely different. However, we provide an adaptor that will allow 5.x menu items to continue to run (for some time) on 6.x.

As to the question of Perl vs. Java, wars have been started over less. I will only say (as a general statement) that support for Java is greatly improved in 6.1.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

However, we provide an adaptor that will allow 5.x menu items to continue to run (for some time) on 6.x.

Does this statement mean to imply that Interwoven plans to phase out perl custom menu item scripts? Or to imply that parameters to these scripts will be passed in a different way to our perl scripts in the future? The adapter is necessary (and was thrown together after 6.0 was released) because you didn't provide a mechanism to pass the parameters we have all been using to our scripts. It was a blunder on Interwoven's part that caused the need for the adapter. What exactly does "for some time" mean?

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

Migrateduser

The difference in the request parameters has nothing to do with whether a menu item is implemented in Perl, Java or any other language. The purpose of the adaptor is to ease migration to 6.x.

Brinko Kobrin
Interwoven Staff Engineer

Adam Stoller

The form variables that are passed by default have changed - such that in 6.x (by deault) there is no 'path_0', 'path_1', 'name_0', 'name_1' etc. - instead there is a list of vpath variables (accessible as an array if more than one) from which you can derive all of that information yourself.

Interwoven provides a pre-processing CGI script that essentially does that for you and translates things into their 5.5.x equivalents - but if you're going to start working on 6.x development you might as well work to the new form variables and avoid the extra perl process overhead.

I created two custom menus on my 6.1 server - "Show Env (New)" and "Show Env (Old)" - the latter using the provided perl script filter - so that I could easily figure out how to retrofit my custom CGIs.

That was also where I figured out that you no longer have to worry about /iwmnt vs. /.iwmnt - as it's now all //server rooted.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com