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

Branching for a website

mohan80

My group is implementing Teamsite 6.7 and we would like to migrate the existing website in to the CMS.

Currently we have a static website (15000+ pages) and we will continue to have a static website once we migrate to Teamsite.
A subject-based taxonomy is being developed to categorize and store content. The plan is to save all DCRs under the taxonomy structure. The subject-based taxonomy differs from the website folder structure.(Website structure != Taxonomy Structure).

The alternative to this is to have the “data” and the web folder structure be parallel.

I just wanted some pointers on what would be a “better” approach.
Or what are the advantages and disadvantages of either approach.

Find more posts tagged with

Comments

Migrateduser

If OpenDeploy is used to push the files from TeamSite to the live webserver then you should replicate the website structure in the branch.

chandraiw

The alternative to this is to have the “data” and the web folder structure be parallel.

duplicate content might be difficult to handle, but you can maintain one set of relationships(taxonomy or website structure) in a database...

Adam Stoller

If OpenDeploy is used to push the files from TeamSite to the live webserver then you should replicate the website structure in the branch.

I agree - basically if you have a website structure of:

docroot/
  - dir1_1/
    - dir1_2/
      - dir1_3/
  - dir2_1/
  - dir3_1/
    - dir3_2/

you want to have the same structure within your workarea (usually mapping the top of the workarea to 'docroot'), and for all your DCRs:


/default/main/www/WORKAREA/work/
  - dir1_1/
    - dir1_2/
      - dir1_3/
  - dir2_1/
  - dir3_1/
    - dir3_2/
  - templatedata/
    - cat1/
      - dtype1/
        - data/
          - dir1_1/
            - dir1_2/
              - dir1_3/
      - dtype2/
        - data/
          - dir1_1/
            - dir1_2/
        - dir2_1/
        - dir3_1/
    - cat2/
      - dtype3/
        - data/
          - dir1_1/
          - dir3_1/
            - dir3_2/

This will make all sorts of processes / customizations much easier to manage. The fact that your taxonomy structure is different should not be a significant problem - if it is, then it begs the question of why the website structure differs from it.

Mr_Cruise

It is good practice that the directory structure in the workarea matches the website and one of the key reasons is to allow virtualisation in the WORKAREA.

One of the biggest problems with TeamSite is the generation of the html or more to point automating it. I have been working on Perl module that maps the DCR to the correct generated file/or directory. This means you could store the content in one structure and generate into another, based on either meta-data or directory.

It is important to understand that you can store DCRs in one structure and generate into another.

I hope this helps.

Adam Stoller

It is good practice that the directory structure in the workarea matches the website and one of the key reasons is to allow virtualisation in the WORKAREA.

One of the biggest problems with TeamSite is the generation of the html or more to point automating it. I have been working on Perl module that maps the DCR to the correct generated file/or directory. This means you could store the content in one structure and generate into another, based on either meta-data or directory.

It is important to understand that you can store DCRs in one structure and generate into another.

Certainly you can - but I'd have to wonder why you'd want to do so?

At a previous customer of mine, we added code into the PT's so that each generated page's relative path (and name) were added as EA's to the DCR so that you could find all pages generated from the DCR easily.

It wasn't a case of a different structure - but a case of

So - while I agree that there is value in being able to find the generated pages from the DCR, I'm not sure I follow why you'd want to use a different directory structure for the DCRs than for the generated pages (it can certainly be done, but I tend to consider that as a badly managed system).

mohan80

BRANCH Content
workarea/
- templatedata/
- domain category 1/
- domain data-type/
- datacapture.cfg
- presentation/
- data/
- SubjectTaxonomyStructure/

BRANCH Internet
workarea/
- Site Structure/
- templatedata/
- domain category 1/
- domain data-type/
- datacapture.cfg
- presentation/
- data/
- SiteStructure/

Where BRANCH Internet could borrow content for reuse from the BRANCH Content
new BRANCHES will be added as other streams come such as INTRANET... who could also borrow from BRANCH Content

too much to explain...
This is an early proposed branching structure for a CMS where the end solution would acheive a high degree of content reuse. (5 yrs away)

does anyone know of other approaches to tackel reuse with interwoven?

Adam Stoller

BRANCH Content
...
- data/
- SubjectTaxonomyStructure/

BRANCH Internet
...
- data/
- SiteStructure/

Where BRANCH Internet could borrow content for reuse from the BRANCH Content
new BRANCHES will be added as other streams come such as INTRANET... who could also borrow from BRANCH Content

too much to explain...
This is an early proposed branching structure for a CMS where the end solution would acheive a high degree of content reuse. (5 yrs away)

does anyone know of other approaches to tackel reuse with interwoven?

Ah - so you would never be deploying from Content to your webserver - you would deploy from Internet, Intranet, etc. to your webserver - yes?

So then the issue comes - how do you access content stored in the taxonomy structure within the Content branch so that it can be used (referenced?) from within the other branches in the website structure?

My gut response would be with DCTs in the other branches that allow you to browse (hopefully intelligently via your taxonomy) through the Content branch and thus place a reference to another branch's DCR in the "local" DCR and then have the PT load that other DCR to access its content when rendering the page locally.

I'm not sure how clear that is, nor what all the potential "gotchas" are - but I think it's generally the approach to use.