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

Integration of components with runtime environment

manish_rathi

SitePublisher is integrated with TS. Whenever a page is to be created or modified, we log in to TS and and modify page. Then why do need components to be integrated with runtime environment ?

When everything is taken care of in TeamSite only, whats the need for components to be in runtime environment ? What is the operation carried by the components in the runtime, when pages are already created or modified in the TS ?

thanks

Find more posts tagged with

Comments

Adam Stoller

SitePublisher is integrated with TS. Whenever a page is to be created or modified, we log in to TS and and modify page. Then why do need components to be integrated with runtime environment ?

When everything is taken care of in TeamSite only, whats the need for components to be in runtime environment ? What is the operation carried by the components in the runtime, when pages are already created or modified in the TS ?

thanks

I'll take a stab at this: Components are not always static, therefore you could have a component perform certain operations when activated in the run-time environment. True, the actions would be specified in the DEV (TS) environment, and might constitute the realm of possible outputs, but some components work off of live-data (e.g.: a stock-ticker component doesn't get its data from TS - it gets it's query parameters, text stylings, layout, etc. from TS - but not the data.

There may be a better explanation, but I think the above qualifies as a partial rationale.

manish_rathi

thanks.
that helps clear some ideas.

Now since components are in run time environment and Dev environment, where does the business user log in to modify the pages ? Does he always log in to Dev environemnt only ? Or does he log in to runtime environment also ?

This is another thing thats confusing me.

thanks

tec_iwov

what do you mean runtime environment? you only need to deploy sites (pages) to runtime the component branch is only for development purposes. the page file contains everything it needs to render in the livesite runtime

manish_rathi

Let me explain problem the way architecture is setup.

To access TS, we can log in to ts by typing url cibc1tsd. We can do the dev work in here. But content managers access cibcDEV.cibc.ca and that comes up with a webpage like real website. Once the content manager finishes work here, he submite the work. QA team can access this work by accessing it on cibcQA.cibc.ca and after its tested ok, work is submitted to staging.

So it looks like content manager is accessing some other page than TS and does the modification work there. But its submitted to QA for testing and to staging, it looks like everything is in TS only. So confusion is, if its in TS, then why is different url address used by the content contributors and testers ? If its the different than TS, then why is it required to use anything else than TS in first place ? Secondly how does content end up in TS staging, if other interface than TS is used ?

thanks

tec_iwov

sounds like you have an extremely custom setup. I would talk to your system architect that setup the system.

In an ootb Sitepub Livesite set up all development is done in a singe TS|SP instance then the content is submitted using the Publish Livesite Content workflow that will submit to staging and deploy content and metadata to the Runtime servers via OD|DD.

I've heard where customers have DEV and Production TS|SP systems but this can cause versioning issues when moving assets from one system to the other.