Parsing multiple DCRs and creating single document

Hi friends,

I am very new to TeamSite and want your help.

I created 1 Data capture form and wrote Presentation template for that. Because the form contains very huge amount of data, I saved that form in multiple parts. So now there are multiple DCRs present for the same Data Type or same form.

When i submit the form, workflow fires "iwgen" command which takes 1 presentation template and 1 DCR as an argument. So while submitting multiple DCRs, It identifies 1 dcr, calls iwgen command on that dcr, creates 1 document. Then again identifies another dcr, calls iwgen comand on that dcr and overwrites previously generated document.

I want to create only 1 document using multiple DCRs. Where should I make changes?

I saw 1 example about Presentation Template provided with TeamSite installation. In that example, they are using iwpt_compile.ipl command which accepts multiple DCRs. Shall i use that command or is there any other way to do the same thing?

I am attaching that example to my post.

Help needed urgently.

Regards,
Nilz

Find more posts tagged with

Comments

Adam Stoller

This is a templating question more than a workflow question - as such - the templating / formspublisher forum would be a better place to ask such questions.

However - since we're "here" ... You can have the PT load multiple DCRs in a manner to incorporate the content from them into a single output page, conversely you can have a PT generate multiple pages from a single (or multiple) DCR.

However (there are always "howevers" ;-) - when you generate a file from multiple DCRs - the generated page will only have an EA that references a single DCR - and that will only happen automatically when you use iwgen. If you use iwpt_compile.ipl - no EAs are automatically added to the generated page - you would have to do that yourself.

A bigger question would be why you feel the need to break the content up into multiple forms for the same DCT. Generally speaking, this is most often done for things like "index" pages which process multiple DCRs to generate a single index page for all of them.

A general suggestion would be for you to consider taking some of the templating courses offered by Interwoven.

Another possibility is that you may really want someting like TeamXML

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

parser

Hi Ghoti,

First of all sorry for not to put a question in a relevant forum.

Now answers to your questions,
>>A bigger question would be why you feel the need to break the content up into multiple forms for the same DCT. Generally speaking, this is most often done for >>things like "index" pages which process multiple DCRs to generate a single index page for all of them.

I have written a form with 5 levels of nested containers. And the amount of data that form will going to contain is too large. Even if I am selecting a New Form -> Entry, it takes minutes to open that form. And after populating that form with data, the form takes ages to open. So i saved that form in multiple parts (and multiple DCRs got created for the same data type.)

>>A general suggestion would be for you to consider taking some of the templating courses offered by Interwoven.

Are these courses offered online? or they provide some Material to read.

I am very new to TeamSite. So if you have some material to read on TeamSite, its architecture, components and other concepts related to TeamSite, plz send me the same.

>>However (there are always "howevers" ;-) - when you generate a file from multiple DCRs - the generated page will only have an EA that references a single >>DCR - and that will only happen automatically when you use iwgen. If you use iwpt_compile.ipl - no EAs are automatically added to the generated page - you >>would have to do that yourself.

So can i achieve my objective using iwpt_compile.ipl? I am not aware of the process of how the resulting page gets created....

Thanx for your reply and please correct wherever found wrong.

Regards,
Parser

Adam Stoller

So - when you're breaking this DCR up - you're breaking it into multiple DCT-types (along [sub] container boundaries)? Or are youi just creating multiple instances of the same DCT in which you are only filling in parts of the entire structure per each DCR?

Are you using inline scripts to set up parts of the DCT?
Are you using VFE textareas ?

Those are two of the most likely candidates for performance issues.

There are some Web-based courses offered by Interwoven for templating training, but sometimes its better to take the plunge (cost- and time-wise) to go through an instructor-led course where not only do you get the material, but you have someone of whom you can ask the more difficult questions in an interactive format. Training material is only [legally] available directly from Interwoven - as part of the cost of taking the training courses.

You can achieve the multiple DCR functionality using either iwgen or iwpt_compile.ipl -- the PT you use to process the DCR can be made to load multiple DCRs during the course of its job - but regardless of which way you go - you need to have a very thoroughly thought-out design to take into consideration all the ramifications of splitting up what is essnetially a single-source of content into multiple sources of content. If you aren't well-versed in TeamSite and TeamSite Templating / FormsPublisher - you're pretty much guaranteed to make mistakes in your design which will translate into failures duing implementation.

So - whether you get your own training, or hire knowledgeable consultants from Interwoven or one of the many consulting companies or independent contractors out there who have that knowledge -- you're going to have to shell out some $$'s to get this right.

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

parser

Hi ghoti,

>>So - when you're breaking this DCR up - you're breaking it into multiple DCT-types (along [sub] container boundaries)? Or are youi just creating multiple instances >>of the same DCT in which you are only filling in parts of the entire structure per each DCR?

Suppose, i created 1 data type "Calendar". It contains, datacapture.cfg, presentation template and datacapture.dtd. Now i gave authorisation to 1 user using templating.cfg. Now the user clicked on "New Form" for this data type. He entered some 10 entries and saved the form with 'calendar1'. He again clicked on "New Form" and saved it with "calendar2". Likewise, he created 2 more DCRs.

I think, this explanation must have cleared the confusion.

>>Are you using inline scripts to set up parts of the DCT?
>>Are you using VFE textareas ?
>>Those are two of the most likely candidates for performance issues.

I simply used the instances which FormsPulisher provides to create a form: Text, TextArea, CheckBox and Select.

Regards,
Parser

Adam Stoller

Suppose, i created 1 data type "Calendar". It contains, datacapture.cfg, presentation template and datacapture.dtd. Now i gave authorisation to 1 user using templating.cfg. Now the user clicked on "New Form" for this data type. He entered some 10 entries and saved the form with 'calendar1'. He again clicked on "New Form" and saved it with "calendar2". Likewise, he created 2 more DCRs.

I think, this explanation must have cleared the confusion.

Okay - so you have a bunch of calendar DCRs and you want a single page created from all of them as opposed to a single page per DCR - yes?

This is similar to an index page - Essentially have the PT find all the DCRs in the data directory and parse them - probably into memory so that you can sort all the results before outputting the content - using iwpt_load_dcr().

Read the documentation on-line at TSservername>http://TSservername/iw/help/tst/pt for more information - also, look through some of the example templates that come with the product.

>>Are you using inline scripts to set up parts of the DCT?
>>Are you using VFE textareas ?
>>Those are two of the most likely candidates for performance issues.

I simply used the instances which FormsPulisher provides to create a form: Text, TextArea, CheckBox and Select.

inlines, and VFE textareas also come out of the box.

If you intend to process multiple DCRs anyway - why not limit the number of instances available for providing calendar information on a per-DCR basis (perhaps even limited to 1 each) and then loading any given DCR won't cause a performance issue.

However, since a generated output file can only be directly associated with a single DCR - this will not help users who start with the generated page and select Edit -- they'll be taken to the DCT form for whatever the last DCR that was used as the instigator of the page generation process. (This would tend to argue in favor of having only a single DCR in which all calendar events were entered - and then you'd probably get into your rendering performance issues).

You might consider putting a "front-end" onto the process - either via workflow or a custom menu item in which the user could specify some aspect of the calendar event they wanted to process - be provided a list of DCRs that match the criteria and then be able to select one of them to perform the editing of. This could also be used to automate the page generation process in a somewhat more logical manner.

You could even consider falsifying the DCR that the generated page pointed to, to refer to a static DCR that simply displayed a message informing the user of the correct process to use for editing calendar events ...

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