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

JSP to Replace DCT

Aleks

Hello,

Has anyone know how to link a JSP file into TS to replace regular way for DCT?
Currently I has a JSP page in the TS UI to instead of a DCT, which means there is a aaa.jsp not file called datacapture.cfg in the template folder. But which config file I need to add this information?

Any replay will be appreciated.

Thanks,
Aleks

TS 6.7.1 on Unix

Find more posts tagged with

Comments

Adam Stoller

Hello,

Has anyone know how to link a JSP file into TS to replace regular way for DCT?
Currently I has a JSP page in the TS UI to instead of a DCT, which means there is a aaa.jsp not file called datacapture.cfg in the template folder. But which config file I need to add this information?

Any replay will be appreciated.

Thanks,
Aleks

TS 6.7.1 on Unix

If I understand your question correctly, there is no such configuration file. This would be 100% custom code attempting to circumvent OOTB features and functionality - you are essentially building your own Edit DCR infrastructure and interface. As such, you would either have to find and modify the OOTB JSPs (slightly supported via copying them into and deploying them from the IWHOME/local/config/lib/content_center/customer_src tree via make_toolkits.ipl) -- or you should create your own custom UI menu item for initiating a call to your custom interface.

Aleks

Thank you, fish.

I don't have an initial UI screen for this JSP dct. But as you said, I just import to the content_center_scr free, template folder of TS UI as well, then using templaing.cfg to write this JSP dct in, it should be working. I just wonder how TS figures out to invoke which DCT because the name of JSP dct is different with the name in the templating.cfg.

Thanks,

Adam Stoller

Thank you, fish.

I don't have an initial UI screen for this JSP dct. But as you said, I just import to the content_center_scr free, template folder of TS UI as well, then using templaing.cfg to write this JSP dct in, it should be working. I just wonder how TS figures out to invoke which DCT because the name of JSP dct is different with the name in the templating.cfg.

Thanks,

At least one of us is very confused.
There is no "JSP DCT" - rather there is a JSP provided in TeamSite that, based upon directives (paths and/or EAs) will process a DCT in an expected path (areavpath/templatedata/category/data-type/datacapture.cfg) in order to create and render an input form. On "submit", once the rendered form is populated and validated, the information is then stored as a DCR in an expected path (.../data-type/data/...) with the appropriate EA(s) attached to it so that if another "edit" request is initiated on it through the provided TeamSite Content Center UI - the Edit DCR window will be launched and the process (much as described above) occurs again.

Aleks

Sorry it is my bad not to explain clearly.
Here is my case: We need to have a DCT, but as usual way it can not have some function. So we decide to have a JSP page to replace regular DCT in templatedata folder.

My question is how can I use JSP page to replace regular DCT in TS? Is there any config file I need to link this JSP file except for templating.cfg.

Hope it clear.

Thanks,

Rick Poulin

Can you confirm that you're looking to use a JSP to render the form, rather than trying to produce JSP as your output? templating.cfg will only let you do the latter via XSLT or TPL, but you're completely on your own for the former.

Assuming we're still talking about the former, perhaps you could provide details regarding what it is that you're hoping to achieve. Your solution seems very heavyweight and there's probably an easier (and better supported/maintainable) way to add functionality to your forms via inline commands and/or FormAPI.

Aleks

Can you confirm that you're looking to use a JSP to render the form, rather than trying to produce JSP as your output? templating.cfg will only let you do the latter via XSLT or TPL, but you're completely on your own for the former.

Assuming we're still talking about the former, perhaps you could provide details regarding what it is that you're hoping to achieve. Your solution seems very heavyweight and there's probably an easier (and better supported/maintainable) way to add functionality to your forms via inline commands and/or FormAPI.

I am trying to use a produce JSP as input form rather than TS' datacapture.cfg. This JSP will be rendered a sitemap, then to be picked up by application server for display.

My question:
1. How to use JSP to replace datacapture.cfg?
2. Could you please explain why my solution seems very heavyweight?

Thanks,

Adam Stoller

I am trying to use a produce JSP as input form rather than TS' datacapture.cfg. This JSP will be rendered a sitemap, then to be picked up by application server for display.

My question:
1. How to use JSP to replace datacapture.cfg?
2. Could you please explain why my solution seems very heavyweight?

Thanks,

Do you have anyone around you with a better command of the English language? I'm not saying that to be rude, but rather because it is somewhat apparent from this thread that those of us who want to help you are not able to do so because we do not understand what you are asking.

As near as I can tell - you're talking about replacing OOTB templating (FormsPublisher) functionality that utilizes DCTs (XML) with some sort of custom templating functionality controlled by JSPs -- if so, you are completely on your own as you are completely avoiding using the functionality provided by the product.

If we are misunderstanding what you are asking (or you are misunderstanding what we are saying) - then you need to find someone who can assist with the translation of the information in both directions - otherwise this thread will go on for ever without any clear indication of whether progress is actually being made.

Aleks

Do you have anyone around you with a better command of the English language? I'm not saying that to be rude, but rather because it is somewhat apparent from this thread that those of us who want to help you are not able to do so because we do not understand what you are asking.

As near as I can tell - you're talking about replacing OOTB templating (FormsPublisher) functionality that utilizes DCTs (XML) with some sort of custom templating functionality controlled by JSPs -- if so, you are completely on your own as you are completely avoiding using the functionality provided by the product.

If we are misunderstanding what you are asking (or you are misunderstanding what we are saying) - then you need to find someone who can assist with the translation of the information in both directions - otherwise this thread will go on for ever without any clear indication of whether progress is actually being made.

Your understanding is correct. The business request wants a good Looking and Feel form with functionality which TS DCT can not be produced as that way. This is the reason why I posted out to use a produced JSP instead of using TS DCT. As you said that will be on my own to avoid using the functionality provided by TS product. I totally agree. So have anyone done this before and what big risk will be?

Thanks,

nipper

Someone needs to tell the business no. Can this be done ? Probably, can it be done cheaply ? No. The costs of development and maintenance make this a very stupid request.

Do they want to spend $250K to develop it and then maybe $50K per year to maintain/update everything ? I highly doubt it.

Adam Stoller

Your understanding is correct. The business request wants a good Looking and Feel form with functionality which TS DCT can not be produced as that way. This is the reason why I posted out to use a produced JSP instead of using TS DCT. As you said that will be on my own to avoid using the functionality provided by TS product. I totally agree. So have anyone done this before and what big risk will be?

Thanks,

The biggest "risk" as that you / your customer will be completely unsupported with regard to any "templating" work as far as Autonomy Interwoven is concerned - and they're probably shelling out quite a few $'s (or corresponding currency) for support / maintenance. You / they will also be unlikely to get any real support from the folks in these forums as, again, this would be a completely customized solution.

The only way that I can think of to provide a semblance of a supported mechanism here would be to have a DCT that contains all the necessary fields (hidden) along with a callout, which would launch your custom application, potentially re-reading the original DCT and rendering it "your" way -- your application would then need to ensure that the information is populated into all the hidden fields so that the actual DCR could be written out correctly and treated as such by TeamSite.

It's kind of hokey, but it's about the only way I can think of that allows you to leverage the product which has been paid for and still provide a more custom look-and-feel.