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

dcr-autonaming - any disadvantages?

jwl

Hi all
TS 6.5 Sol9
I've just discovered dcr-autonaming for templating.cfg and am quite excited by it in terms of making things easier for our customers. I'm testing it against most of my data-types and I'm wondering whether there'd be any disadvantages to using this, given that we have a 1:1 mapping between all our generated files and DCRs.

Also, in our current setup the templatedata directories have subdirectories underneath them, but I'm wondering whether there's any need for this. If not, dcr-autonaming would save the DCRs all under the immediate templatedata/'data-type' directory. Will there be any problems with having all the DCRs under a flat directory structure?
Thanks,
John

Find more posts tagged with

Comments

Adam Stoller

I'm generally in favor of creating DCRs within the context of a workflow - pre-naming them based on logic inherit within a *design* and now allowing users to create DCRs outside of that context. In that scenario - the autonaming feature isn't used.

Is there a problem with putting all the DCRs directly into the data/ directory - yes and no. When you get over 500 or 1000 files within a single directory, some operations take considerably longer than they would if you had instead spaced them out under several sub-directories. In theory, TS 6.x off-sets this problem by actually dividing the files in the backing store into multiple directories and having them mapped virtually to appear as if they are all in one directory - that, plus the UI allows you to limit the number of files rendered within a directory listing so as to not pay too high a performance penalty in rendering time. However, using sub-directories yourself and limiting the number of entries within a directory to something under 500 is still a better process all around.

I haven't used the auto-naming feature, but I'd think you could have it insert sub-directory paths too -- the only thing that might be required is to pre-create the sub-directory structure (i.e. I don't think autonaming will auto-create directories on the fly)

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

gzevin

I'd second fish on his reasonong. IMO, the best approach is to drive most of things via workflow.

In many cases I create a directory structure in the data directory. So the users *know* where to place DCRs... In some cases a workflow could capture DCR path and generate appropriate target file based on DCR path

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

sum_aggregate_on_grid.rptdesign

LooseCannon

The biggest disadvantage is that the file name isn't descriptive of the file’s content it's not intuitive. This make’s it difficult for the authors to locate their files. Personally I'm a big fan of auto-naming DCRs either with a workflow or custom FormAPI.

Johnny

There is a function in form api that allows you to override the default naming convention.

So you can control it there, though it's purely on the client side. The function must return a string for the dcr name - it would have been better to use a callback so that you could do something like a callserver action or other non blocking/event based task.

Can't remember the name off the top of my head for the function sorry.

John Cuiuli

LooseCannon

Oh right, I forgot about that :-)

sum_aggregate_on_grid.rptdesign