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

Same data type name, different branch

LeeCharlebois

Is it possible to have two different data types with the same name on different branches? Example templating.cfg:

[html]

[/html]

Right now what's happening is I can't do a "File->New Form Entry" from the mediaroom branch - getting the this data type is not setup for this branch error. Thanks!~

Find more posts tagged with

Comments

Migrateduser

Right now what's happening is I can't do a "File->New Form Entry" from the mediaroom branch - getting the this data type is not setup for this branch error. Thanks!~

why not just name the tpl the same and do something like:
[html]

[/html]having only 1 entry.

Migrateduser

or I believe this should be OK too[html]

[/html]

moonkhanna

It is not possible to have two data types with the same name in templating.cfg. Since you are using different branches, you can instead have a different datacapture.cfg for the same Data type in both the branches..

ISCBorisB

It is not possible to have two data types with the same name in templating.cfg

That's incorrect. It is certainly possible. Proper access is granted through location Tags regexes and usage of "prune-missing-files" attribute of the <templating> Tag.
You may want to see some discussion [thread=21307]here[/thread]

Frederik

I guess moonkhanna meant to say that in TEMPLATING.CFG, you can NOT have more than 1 category of the same name
[HTML] ...
[/HTML]
or more than 1 type under a category, of the same name
[HTML]

...

[/HTML]
The templating.cfg parser will not report an error, but only just remember the latter (or maybe the former?) of duplicate instances.

EDIT: forgot to comment that the above problem is ANNOYING as ****, because we like to have the TS config files maintained as the sum of partial fragments supplied by the different projects that use TS. But in this case, we need to manually merge the different fragments that are needed for otherwise separated and unrelated projects.

ISCBorisB

You absolutely can use identically named Categories for different Branches providing that you segregate
them using branch regexes. These identically named Categories absolutely can have all sort of types, identically
named or otherwise.

In other words, you can configure Category_A/Type_B/Presentation_Template_ABC in one Branch and
Category_A/Type_B/Presentation_Template_XYZ in another if that's what you want. (Note also that
if Category/Type/PT names/Access rights etc, are identical for the various Branches, single Category Entry
with sub-elements is perfectly adequate to cover both).

Just about the only thing you can not do is to have the same (not identically named, the SAME!) Branch/Category with
several identically named Types

Frederik

Boris, Did you try that on your server?

Because that's simply not true on my TS 6.5 SP2 + patch 1767 on Solaris 9.

having the following in templating.cfg

[HTML]

[/HTML]
... and all the DCT, PT files in both /iwstore02/main/branchA and branchB (not the default store, but I guess that has no impact)
... will make the template aboutus/pageB available in ONLY the branchB.

If I reverse the order of these 2 < category > elements, then I get only aboutus/pageA in branchA.

I've tried this with both prune-missing-files="t|f"

Thus proving that if you have 2+ < category > elements in templating.cfg with the same name attribute value, the parser will only remember the last entry.

YMMV, but that would be surprising.

ISCBorisB

Did you try that on your server?

I did more than that. I've used it before and I use it in my current Project.

Thus proving that if you have 2+ <category> elements in templating.cfg with the same name attribute value, the parser will only remember the last entry.

Described *masking* functionality may well be true, perhaps we can even find some use for it one day. However, that simply seems to be a wrong configuration.
If I understand your requirements correctly, you want something like this[html]

[/html] Or this[html]

[/html]Check out this old Article, what it says is true still.

Please note that the vpath-regex attribute of <branch> of your presentation template is matched irrespectively of category and data Type vpath-regexes,
that provides for both inventive usage and subtle problems. Note also that <locations> Tag on any level may contain multiple <branch> Sub-tags

Frederik

Described *masking* functionality may well be true, [...] However, that simply seems to be a wrong configuration.

Boris, I'm not the one having a problem in this thread ;-) I just wanted to emphasize, for the original poster and for anyone who cares to listen, that the templating.cfg configuration does not allow you to have 2 < category > XML elements of the same name.

THEREBY, as you illustrated yourself with your configuration examples, one CANNOT just concatenate the templating.cfg fragment for Project A and that for Project B. Instead, one has to merge the 2 fragments intelligently - adding to the complexity of keeping the templating.cfg file updated when the TS server is used for multiple independent projects (in separate branches).

I believe we agree... I just emphasize the current weakness (failure to simply concatenate parts), while you emphasize the workaround (merge structures) ;-)

EDIT: compare this with available_templates.cfg or submit.cfg which CAN be constructed as a simple concatenation of fragments provided by different projects.

ISCBorisB

I believe we agree... I just emphasize the current weakness (failure to simply concatenate parts), while you emphasize the workaround

Yes, I would certainly agree. I may even concede that IWOV "Branch Tree - templating XML" mapping schema may be wanting in some merging
scenarios. That said, I do not think that what I've illustrated is a workaround. It is IMO exactly the intended usage of the nested locations
Tags.

We can of course argue pros and cons of different mapping schemas (one day, over good beer). "available_templates" is a poor comparison choice, it is
always very shallow (I've seen 3 levels once in my life and 4 never). Submit.cfg is an excellent one. Note though that: a) It has been designed by die-hard
LISP fan and general IWOV standard is XML and b) Ease of merging was probably not the most important criteria when templating.cfg structure has been
considered (if it was a consideration at all)