How to handle very large DCRs?

tobias

Hi there,
to create configuration files containing key-value-pairs we have DCRs with hundreds of replicants, each replicant being rather simple (basically containing two elements for "key" and "value").
However, these DCRs are unmanageable by the end user. So we are thinking of various ways to somehow split the DCRs' content into chunks.

a) One solution would be to simply create various DCRs, store the ones that belong together into the same subdirectory and have either the TPL or the workflow combine them to a larger output file.
The downside to this is that if the user doesn't save the DCRs that belong together in the same directory the resulting (combined) file will not contain all necessary information with the possibility to crash the entire application on the webserver.

b) Keeping all information in a single DCR we could desing the DCT to only display chunks of the content at a time. This could be accomplished via FormAPI and a dropdown list at the top of the DCT. Depending on the selected option in the dropdown list, the appropriate section (i.e. 50 instances of the simple replicant) would be displayed.
This solution would prevent the user from easily finding the content he wants to edit since he will probably not know which section of a DCT the content is stored in. So he would have to go through the sections looking for the content he wants to change.

Did anyone ever run into a similar requirement? If so, how did you solve it?
Any other comments are welcome and appreciated.

PS: This is TS6.5 SP1 on Solaris.

Adam Stoller

Is there any kind of validation being performed on either the key or value parts of the key/value pairs?
Is there anything else being stored in association with each key/value pair?

If not - you could opt for a single textarea (or perhaps multiple text areas in case too much data is entered into one?) and do a simple validation of the contents (onSave) to verify that all lines are of the form xxxxx=yyyyy.

It's not an "elegant" solution, but probably more manageable from the GUI rendering view point - and the PT can break each textarea's content up into separate lines and then by key and value to do whatever it is you do with these entries.

Just a thought - not sure it's the best idea, but I think it would work.

NewSRList.zip