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

Central collection of datacapture.cfg files

kremer

Is there a way to set up a central collection of datacapture.cfg files so that they can be used by all branch/workareas in a given store without having a copy of each in every single workarea? Any change made to a DCT has to be replicated to the other branches/workareas, and when a new branch/workarea is created, we have to copy them all.

Find more posts tagged with

Comments

LMX

I've used 2 different approaches:

1) Find a good search and replace tool Smiley Happy

Keep your DCT code consistent in order to enable efficient S&Rs.

2) Use XML entities to point to a central repository. You'll still need a DCT in every branch (obviously), but at least you could have all of the real code (scripts, content nodes, etc.) living in a central location. The datacapture.cfg files simply contain multiple pointers to different chunks of code.

Good luck.

nipper

All my DCTs are stubs that have an inline statement to a script that builds the DCT on the fly. That is by far the best approach. Same with TPLs

Andy

LooseCannon

All my DCTs are stubs that have an inline statement to a script that builds the DCT on the fly. That is by far the best approach. Same with TPLs

Andy

x2
.............................

kremer

The method I'm using actually queries an excel spreadsheet for DCT definitions, so all of the DCTs are the same, and the .tpl just points to an appropriate perl module for processing depending on category and data-type, but what it sounds like is the datacapture.cfg and .tpl for each DCT have to be in each workarea. Correct?

My biggest grief is that when I create a new template, the exact same datacapture.cfg and .tpl needs to copied to nearly 180 workareas. I have a relatively painless method of doing so, but it would be nice to have a central location for the datacapture.cfg and .tpl files instead of having so many copies floating around.

ccprofessional

DCTs as stubs which point to a central repository of scripts/xmls files is a fine idea.

But the question is why do you have hundreds of workareas?

Perhaps you can club the workareas together (where applicable ofcourse) and use OS permissions, etc to deal with the rest.

IMHO, having one workarea for each user(not sure if thats how you have it) is an over-engineered concept.

moonkhanna

The method I'm using actually queries an excel spreadsheet for DCT definitions, so all of the DCTs are the same, and the .tpl just points to an appropriate perl module for processing depending on category and data-type, but what it sounds like is the datacapture.cfg and .tpl for each DCT have to be in each workarea. Correct?

My biggest grief is that when I create a new template, the exact same datacapture.cfg and .tpl needs to copied to nearly 180 workareas. I have a relatively painless method of doing so, but it would be nice to have a central location for the datacapture.cfg and .tpl files instead of having so many copies floating around.

Good question by ccprofessional. Also, as Andy stated, just build your DCTs on the fly. Yes, you will need to have appropriate datacapture.cfg with the inline command as well as the templatedata directory hierarchy in all your workareas

gzevin

All my DCTs are stubs that have an inline statement to a script that builds the DCT on the fly. That is by far the best approach. Same with TPLs

Andy

however, as I was told, Data Deploy has issues if you inline the DCT. I have not tried this with DD. Have you?

kremer

IMHO, having one workarea for each user(not sure if thats how you have it) is an over-engineered concept.

There isn't a workarea for each user. Our live web site has over 30,000 pages, representing global and regional content. To keep our users from getting confused, the branch structure follows the region/country/language/business sector of the content they are assigned to work on. We previously had 1 large workarea, and we had problems with people messing with content they shouldn't be (whether intentional or not), not being able to easily find their own content and slow server performance from everything being listed at once for each user.

nipper

There isn't a workarea for each user. Our live web site has over 30,000 pages, representing global and regional content. To keep our users from getting confused, the branch structure follows the region/country/language/business sector of the content they are assigned to work on. We previously had 1 large workarea, and we had problems with people messing with content they shouldn't be (whether intentional or not), not being able to easily find their own content and slow server performance from everything being listed at once for each user.

Your new approach sounds like the correct way. It makes DCT creation as preview *interesting* however those are things you can solve. Shared images are a pain, look carefully at that issue and think it though carefully. I am speaking of images that might be referenced in DCRs. Esp if you try the best practice of deploying images if a DCR references it and that image is in a different workarea.

Do yourself a favor and write a DCT/TPL deployment script. Have one master set of DCTs (that just include the inline) and TPLs that you can deploy to a new branch or overwrite all in the unlikely case of it needing to change. Happens most often with TPLs (but you probably have already fixed the BOM of all the TPLs)

Migrateduser

I must say that I like the idea of using the inline command to build the DCT's on the fly. However, I ran into some problems when using this approach together with datasources.

Here's my scenario:

I keep my master-DCT's in branch1.
In branch2 I keep my DCT's with my inline command that builds the DCT on the fly based on the DCT in branch1.

When having a the following in my master-DCT it fails to return data&colon;


..
...
select required="t">
  inline command="Datasource:executeComponent:myDatasource"/>
/select>
...
..

Did anyone come across this problem?

zone vandalism.rptdesign

vpatel

It fails in Master branch or secondary branch or both?

Migrateduser

It fails in Master branch or secondary branch or both?

In the secondary branch (branch2).
It doesnt fail in terms of an error message. It just doesnt load any data from the datasource.

parseParam.rptdesign

vpatel

You getting any error in the log file?

Migrateduser

Nope.
No errors in the logs.

-When I open the DCT in branch1 the datasource returns data.

-When I open the DCT in branch2 (this one is reading the DCT from branch1 with an inline command) the datasource returns null as if it isnt fired at all.

Adam Stoller

Nope.
No errors in the logs.

-When I open the DCT in branch1 the datasource returns data.

-When I open the DCT in branch2 (this one is reading the DCT from branch1 with an inline command) the datasource returns null as if it isnt fired at all.

Are you saying that you have a DCT in branch2 that uses an inline script to read a DCT in branch1 that has an inline script to run a datasource?

If so - no wonder. Inline script processing is not recursive. This has been posted about before and if you want to understand more about it, I suggest you search for and read those posts.

If that isn't what you are doing - then please try again to explain clearly how you have things set up.

Migrateduser

Are you saying that you have a DCT in branch2 that uses an inline script to read a DCT in branch1 that has an inline script to run a datasource?

If so - no wonder. Inline script processing is not recursive. This has been posted about before and if you want to understand more about it, I suggest you search for and read those posts.

If that isn't what you are doing - then please try again to explain clearly how you have things set up.

Thats exactly the problem. Thank you.