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

Optimal branching/workarea structure

sgouin

After reading the "Definitive Guide to Interwoven Teamsite", I must say it was quite educational. Without Teamsite training under my belt, this book was a blessing... of course devnet forums are essential as well.

My question is relating to branching and workarea set-up... I have created a main branch with a number of sub-branches each with their own respective workareas where needed. The idea stems from our organizational style guide, where a corporate branding is required across all sub-sites, and each sub-site having some specific areas within the "template" to control. For example, the overall page width must be a fixed size, 3-column layout, with specific sizes for sub-site banner, and other mandatory corporate graphics must be present. etc...

The top-level branch provides a workarea with component TPLs to generate the mandatory corporate pieces of content in the site template. The content for some of these pieces are captured in the sub-branch (sub-site branch)..

The model I have basically captures content in different sub-branches, some of which are generated using TPLs or component TPLs from parent branches.

I'm having issues obviously with image links etc... I have corporate images stored in the top level branch workarea, which are pulled in a component TPL. This component TPL is "included" (iw_pt include call) in a sub-branch TPL... the images are obvsiously broken, since they are relative to the containing workarea...

Just wondering if anyone has any advice, guidance on whether or not I'm on the right path and if this is common practice...

This is a very broad subject, hopefully I've provided enough context for my situation.. if not please let me know and I will try to clarify...

Thanks

Find more posts tagged with

Comments

Adam Stoller

...
I'm having issues obviously with image links etc... I have corporate images stored in the top level branch workarea, which are pulled in a component TPL. This component TPL is "included" (iw_pt include call) in a sub-branch TPL... the images are obvsiously broken, since they are relative to the containing workarea...

Just wondering if anyone has any advice, guidance on whether or not I'm on the right path and if this is common practice...

This is a very broad subject, hopefully I've provided enough context for my situation.. if not please let me know and I will try to clarify...

Thanks

Assuming the image links are area-relative paths and that those paths will work when the pages and images are pushed to a web server (i.e.: the same relative path from the doc_root) - then you need to look into configuring iwproxy in the iw.cfg file - read the TeamSite Administration Guide for more details on that.

sgouin

Thanks Fish.

From what I see, iwproxy_remap is key, the caveat is it only works on the default content store...

I found DCTs and TPLs fairly easy to pick up... it's all the other stuff (workflow, architecture, configs etc) that are a bit more challenging and where I need to focus my efforts...

I guess the other part of my question was to get feedback on the branching structure and the logic behind it... I figure the short answer to this one is, there's more than one way to get the job done... but if anyone can share some info, it's greatly appreciated...

Again, my thinking around the branching structure was to build a hierarchy, using a parent branch and sub-branches. Each level representing a level in our organization so we can apply styling guidelines and controls. For now, each branch only has one workarea... I don't think we want to get into parallel content development and resolving conflicts in the staging area...

The objective is to also set-up a structure to easily create other sites within a particular level in the organization, without having to re-code the common pieces. (cookie-cutter websites)

If any customizations or additional captures are required, then they can added to the respective sub-branch...

Adam Stoller

Thanks Fish.

From what I see, iwproxy_remap is key, the caveat is it only works on the default content store...

I don't have a system to play with right now - but I'm not sure that limitation is real. As I recall, the URI path that is processed on the left-hand-side tends to start with

/iwmount/store/main/...

which means you should be able to map it to

/iwmount/another-store/main/...

if you want to do so (and/or maintain the store name even if it isn't

default

)

Again, my thinking around the branching structure was to build a hierarchy, using a parent branch and sub-branches. Each level representing a level in our organization so we can apply styling guidelines and controls. For now, each branch only has one workarea... I don't think we want to get into parallel content development and resolving conflicts in the staging area...

Well - the short answer is "it depends".

For many organizations, the hierarchy is handled via a directory structure within the branch rather than a hierarchy structure of branches - but for other organizations, yes, an hierarchy of branches can be used too (in fact, I think my current customer does something along those lines - I'm just involved in an upgrade effort right now - not designing their customizations)

In terms of images and such - consider having something like a "global" or "common" [sub-]branch (or sub-directory, depending on which hierarchical approach you take) in which you create directories like "global_images" and/or "common_css", etc - and then within the departmental branches you can have a directories like "images" and/or "css". In this way you can tell via the path reference whether the asset being referenced is a global or local asset and handle the proxy mapping accordingly.

Note - the same should be done for the web server docroot - i.e.:

htdocs/
- global_images/
- global_css/
...
- department-1/
-- images/
-- css/
...
- department-2/
-- images/
-- css/
...

The trick is to make sure you have a directory structure both on the web-server and in TeamSite that can easily be mapped in a 1:1 relationship so that all embedded references can be resolved with a simple proxy in TS and (preferably) without a proxy on the web server.

Furthermore - when you work with templating, remember to create a directory structure under the

data/

directory that maps 1:1 with the content directory structure that appears either from the root of your workarea or within a sub-directory thereof that acts as-if it were the docroot. i.e.:

workarea/
- hr/
-- html-pages
-- subdirs-with other html-pages
- news/
-- html-pages
-- subdirs-with other html-pages
...
- templatedata/category/data-type/data/
-- hr/
--- DCRs
--- subdirs-with other DCRs
-- news/
...

This kind of correlation of directory structures will make so many things so much easier.

nipper

I don't have a system to play with right now - but I'm not sure that limitation is real.

Can't get VMWare running on your Commadore 64 huh ?

Oh, thats right, you have a Mac. A different toy computer. :-)

Adam Stoller

Can't get VMWare running on your Commadore 64 huh ?

Oh, thats right, you have a Mac. A different toy computer. :-)

Actually - I probably could get either VMWare or Parallels to run on my Mac - but I'm not sure I'd want to do so - as it makes it easier to not do other people's work for them ;-)

sgouin

I
Furthermore - when you work with templating, remember to create a directory structure under the
data/
directory that maps 1:1 with the content directory structure that appears either from the root of your workarea or within a sub-directory thereof that acts as-if it were the docroot. i.e.:
workarea/
- hr/
-- html-pages
-- subdirs-with other html-pages
- news/
-- html-pages
-- subdirs-with other html-pages
...
- templatedata/category/data-type/data/
-- hr/
--- DCRs
--- subdirs-with other DCRs
-- news/
...
This kind of correlation of directory structures will make so many things so much easier.

Thanks Fish. I agree with that approach, and was kind of heading in that direction. Just keeping it simple is usually the best option.

We were told by a consultant that the internal TS structure did not have to "match" or correlate to the external (generated) public facing structure, the two could be different, so that the internal structure could be modeled best for internal authors, based on the organizational structure, and but be represented differently for the public-facing website.

Personally, I don't think the public cares much about URLs, as long as the content is displayed and organized appropriately.

If I understand correctly, although the above is "possible", it would be a mess of proxy redirects and mappings, and most likely complicate the workflow and deployment process... too much complexity and not much value-added...

Adam Stoller

Thanks Fish. I agree with that approach, and was kind of heading in that direction. Just keeping it simple is usually the best option.

We were told by a consultant that the internal TS structure did not have to "match" or correlate to the external (generated) public facing structure, the two could be different, so that the internal structure could be modeled best for internal authors, based on the organizational structure, and but be represented differently for the public-facing website.

Personally, I don't think the public cares much about URLs, as long as the content is displayed and organized appropriately.

If I understand correctly, although the above is "possible", it would be a mess of proxy redirects and mappings, and most likely complicate the workflow and deployment process... too much complexity and not much value-added...

I agree - you could organize the directories completely differently - but I think you lose far more than you gain by doing so.

Even for those users who are not particularly URI-inclined - if they're looking at a page on their web site like hr/about_us/index.html - I think they'd be able to figure out a directory structure in which there was an 'hr' directory and within that an 'about_us' directory - and lo-and-behold an 'index' DCR or 'index.html' page.

The consistency of directory structures works for both users and automation / customizations alike - anything else is just asking for more work (and not the "fun" kind either - more the "pulling-out-your-hair" type)

ISCBorisB

If I understand correctly, although the above is "possible", it would be a mess of proxy redirects and mappings, and most likely complicate the workflow and deployment process... too much complexity and not much value-added...

You seem to be correct in your particular case. In general however that (citing Ghoti :-) depends. Please note that
a)There is no "one size fits all" optimal branching strategy. You'll need some guidance and a lot of personal experience to get a feeling for it.

b) Branching/WAs/Folders structure is IMHO single most important aspect of TS implementation. It is always a compromize. The key here is to be able to make conscious decision (like "That simpler structure will improve authors' experience but complicate development and maintenance", this sort of things...)

c) "Double mapping" of site structure under WA pseudo-root and templatedata works wonders if you have one-to-one correlation between DCRs and generated Pages. It should not be used however if you generate multiple related assets from the single DCR and/or *live* site structure is virtual (both is often the case with Application Servers). You will need more elaborated mapping mechanisms ih such cases

nipper

We were told by a consultant that the internal TS structure did not have to "match" or correlate to the external (generated) public facing structure, the two could be different, so that the internal structure could be modeled best for internal authors, based on the organizational structure, and but be represented differently for the public-facing website.

Personally, I don't think the public cares much about URLs, as long as the content is displayed and organized appropriately.

I have always kept my TS implementations in sync with the directory structure on the production site. You can work around that without question, but keeping the overall structure is a good thing.

My current project has a main branch with a ton of content, and 20 some odd sub branches that have business unit specific content. URLs are consistent and the proxy remaps are quite extensive but it gives the most flexibility and security.

You would also be surprised how much the public cares about pretty URLs. Anyone doing SEO (search engine optimization) will work hard on the URLs. The URL is one key parameter sites like google & yahoo use to rank the sight for a specific keyword.

Andy

sgouin

You seem to be correct in your particular case. In general howevr that (citing Ghoti :-) depends. Please note that
a)There is no "one size fits all" optimal branching strategy. You'll need some guidance and a lot of personal experience to get a feeling for it.

This marks the beginning of a beautiful relationship with me and Interwoven Teamsite. Perhaps a certification will be part of our future.

I'm just getting started with the product, but I see a lot of potential uses for it within our organization. The sky's the limit...

ChangeAxisTitle.rptdesign

sgouin

You would also be surprised how much the public cares about pretty URLs. Anyone doing SEO (search engine optimization) will work hard on the URLs. The URL is one key parameter sites like google & yahoo use to rank the sight for a specific keyword.

Andy

True... our client does care to some extent. They would like "friendly-urls", for marketing purposes etc.. and providing main entry gateways for the public is easier for them to remember if it's short and sweet... but for Joe Public who hits our site through search pages, probably not as much of a concern...

Never considered the impact on SEO.... makes sense

Thanks guys for all the replies and feedback... much appreciated.

nipper

True... our client does care to some extent. They would like "friendly-urls", for marketing purposes etc.. and providing main entry gateways for the public is easier for them to remember if it's short and sweet... but for Joe Public who hits our site through search pages, probably not as much of a concern...

True but Marketing typically pays the bills for the Web, so when the VP of Marketing says jump.......

gzevin

Can't get VMWare running on your Commadore 64 huh ?

Oh, thats right, you have a Mac. A different toy computer. :-)

his Mac probably runs on Intel now. So he can put a real OS there. and run VM Ware Smiley Happy

Adam Stoller

his Mac probably runs on Intel now. So he can put a real OS there. and run VM Ware

Jealousy will get you no where ;-)