Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
THRUST SERVICES & TOOLS
CLOUD EDITIONS
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Templating Alternative
System
Can we use Java programs or JSPs to create a DCR instead of using Teamsite Templating because Templating is not very flexible and it has limited scope when Dynamic templates need to be created?
Is OpenAPI a good option for creating Dynamic templates?
Thanks
Find more posts tagged with
Comments
james1
The format of DCR's is fairly open. Lots of people have automated processes that slurp in data from some data source and then write the data out as TST DCR's. So you should feel free to write your own application that writes out DCR's. Just make sure the DCR is in an appropriate format (for IWOV-type DCR's, make sure the items and values are arranged properly ... you can use TST to write out sample DCR's to verify your DCR's against) and make sure to set the EA on the DCR, assuming that you want the rest of the system to recognize that file as a DCR.
I'm not sure I see how OpenAPI can help you create your hypothetical GUI.
Have fun.
-- James
PS - Feel free to communicate your perceptions of TST's shortcomings to any IWOV people you may come into contact with, e.g., DevNet forums, sales reps, Tech Support. We rely on customer feedback to guide us in future development.
--
James H Koh
Interwoven Engineering
Migrateduser
We are planning to use java (jsp) to create the gui. This gui is fairly complex and it is totally dynamic based on user inputs. It is to be implemented in the form of a wizard and has more than 10 dynamic pages. The user will enter all the fields in the gui and on save our application will create a XML in DCR and use OPenAPI to save it in interwoven.
MY questions are ==>
1. Is there an OpenAPI component that will create a DCR from an Java Object ?
2. Functionally when the user clicks on a DCR, it should open our java application. How is it achieved in interwoven ?
Migrateduser
You could use anything to write the XML for the DCR (maybe com.megginson.sax.DataWriter or something from Apache), then use either command line tools or OpenAPI to set the attribute on the file to indicate it is a DCR.
You could put FormAPI in the DCT to redirect to your custom Java application, so the user would still use TeamSite edit button to edit content. Performance would suck because it would still bring up all those nested frames in the data capture form before redirecting. You could do it with a custom menu item to skip that step (still do the DCT solution, but add the CMI to go right to the custom application).
But why use DCR format at all in this case? Why not use a custom XML format and XSLT?
Migrateduser
The requirement is creating a contenet authoring tool, that has metadata about a page (Like header, Footer, Body, Launch Date and Expiration Date etc). All this metadata about this page is stored in database. These pages are created in JSP, by querying the page metadata from the database.
Let me explain the flow that we are envisioning.
1. The user clicks on the menu button.
2. The java application is invoked
3. The user saves the application.
4. A DCR or XML is created and saved in teamsite
workarea using OpenAPI. At the same time test database is updated.
5. The user then invokes the teamsite workflow, and attaches the XML or DCR to the workflow.
6. The approver previews it by clicking on the JSP link.
7. After approval, it is moved to team site's staging and edition.
8. On LAunch Date, the DCR or XML is used to deploy data using data deploy to the production database. OPen Deploy is used to move the static files attached in workflow to production.
9. If the approver rejects the change, then the submitter must be able to modify the DCR or XML by using the same java application.
My questions are --
1. I understand that DCR is not needed, but we thought that sing DCR is an XML, we will stick to it. Do you think our assumption is correct.
2. When the approver rejects the change, the submitter needs to click on the DCR or XML to invoke the java application. We do not want to use the formAPI in the DCT to redirect to the java application because of performance problems. Can you suggest some other way ?
anilp
i work for Interwoven.
Couple of notes about your requrements..
1. For pulling the metadata into the template, you can use FormAPI - essentially you would have the relevent items built into the template and populate the values of these items with the metadata you read from the database using JavaScript based FormAPI functions. you don't seem to necessarily need to go the custom JSP or Java applicatoin route to meet this requirement.
2. updating the databse when a record is saved - this can be done using FormAPI as well, by writing a JavaScript function that is associated with the onSave event trigger. Or you could use a simple non-user facing workflow that is hooked with a DCR-edit event to accomplish the same, or even a DataDeploy configuration. TeamTurbo might be provide additional benefit here, but i don't know for sure.
3. proper virutualization of JSP generated from the DCR for preview purposes most likely will require TeamTurbo, which essentially links a TeamSite workarea to an app server sandbox for virutalization purposes.
i will let others address your specific questions.
- anilp
imsmanifest.xml
Migrateduser
To pull the metadata with FormAPI, don't you still need to write some server side code to retrieve the extended attributes? It would be great if Interwoven could write this API instead of making all customers write it (maybe it already exists and I just don't know where the docs are?). If the metadata already exists maybe you could use inlines in the DCT?
There are so many limits on what FormAPI can do vs. what you can do with a real application page, and anyway they want a better UI than the templating UI if I understand correctly. My last customer wanted to do the same thing with ASPX - when you are used to building forms in an application language, building them in a DCTs is really ugly. FormAPI in this context seems like a kind of hack to interact with the server without using a sever-side page. Be aware that VFE probably won't work (for licensing reasons) in a custom templating application.
You can virtualize a JSP a lot of other ways than buying into more Interwoven software that doesn't work in all cases. It's a hack, but you can set up a presentation template to generate an HTML file that redirects to the JSP page passing the appropriate URL parameters or doing a form post to the JSP page if needed, and generate and attach that file to the workflow job.
Shouldn't DataDeploy with DAS update the DB when the record is saved? Not that I would ever recommend DD - I would write SQL calls in a custom JSP for better control.
It sounds like a big project any way you go about it.