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

Referencing datacapture.cfg lying in some other branch

ngogia

Current scenario –

We have 5 different sites, all of them use same code (for datacapture.cfg and TPLs)
Currently, the code is being worked upon in one branch and then it is deployed on all the 5 site specific branches.

Requirement –

We need to put the code in a common location and reference it in the site specific branches. This will dissolve the requirement of deploying the code on all the branches. The code will be changed at a common location and will just be referred to in the site specific branches.

Can we somehow manage it via inline or by any other way? Any other suggestions/solutions?

Find more posts tagged with

Comments

Migrateduser

Inline is exactly what I would have suggested. Typically, where you have code that you need to reuse, it's good practice to call an inline to render the XML.

I don't know which version you're on or if 6.7 addresses this differently, as I haven't gotten my grubby hands on 6.7 as yet -- other than that, an inline is a popular way to mitigate reused DCT components.

ngogia

We are using version 6.1. We have already coded all the DCT and TPL's and now they want to change the whole structure by putting the code in some other branch. What would be the best way to achieve this

Migrateduser

Okay, well then you'll need an inline to render the "foreign" XML. Your inline could be so generic as to take an argument (or if you want to use GetOpts, that's better) that describes the path to the XML component. All your script would then do is to render whatever file you pass in as the argument.

That's an example -- I'm not claiming it to be the best scenario but it's a pretty simple one.

Adam Stoller

We are using version 6.1. We have already coded all the DCT and TPL's and now they want to change the whole structure by putting the code in some other branch. What would be the best way to achieve this

For DCTs, as Dave as pointed out - inlines are the way to go (though you might also want to look at [thread=7019]this thread[/thread] regarding a FR that was filed to make this kind of thing easier [IMO])

For PTs - I would try to write them all in Perl and use Perl modules (stored in IWHOME/iw-perl/site/lib/) so that you can abstract the code more easily for code reuse. The other alternative is to have all the "local" PTs use an <iw_include> of the "centralized" PTs. The optimum would probably be a combination of the two approaches (or the FR as referenced - but that doesn't help you in the here-and-now)

RonaldV

Hi,

we have the same requirement and we have it solved by means of a perl-script that does a "smart" compare and then syncs the templating-code. Nasty, complex script. Not something you would write on the back of an envelop.

Maybe one could use symlinks when on unix but I'm unsure whether TS supports them.

And yes, Iwov should be doing a better job in supporting this OOTB.

Cheers, Ronald

ngogia

Using inline solves the problems for datacapture.cfg (we just need to change the .cfg files to valid .xml files that can be inlined)

BUT, we are not able to inline any javascript code. The javascript needs to use the FormAPI also.

Is there a way, we can do this??

notdefined.jpg

Migrateduser

You can't inline FormAPI but you can do this, which accomplishes the same thing:

<script language="JavaScript" location="webserver" src=""/>

I suggest you read the FormAPI and Templating documentation for more detail.