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

DCT Navigation Builder

dkuntze

I'm new to TeamSite, so forgive me if I'm asking questions that have been answered many times before. I've done some searching in the forums for the last couple of days about how TS developers build their websites' navigation elements. I'm in the process of developing a moderate size web project using TS 6.5 and I was wondering what the "best practices" are for creating managing the site navigation.

I've seen the solutions that involve a separate 'nav' DCT from the 'page' DCT creating two DCRs. While this will certainly work, I see it as non-ideal. I'm looking for more of a monolithic approach... ecapsulating navigation within the 'page' DCR. That way, if a 'page' DCR is deleted, you also lose the navigation (no broken links). Is this a valid approach? Are there better ways?

Any advice you can give would be much appreciated. Any sample code would also be appreciated.

Thx,
DK

Find more posts tagged with

Comments

Migrateduser

What I've done is an approach that incorporate some of Vignette's native functionality into Teamsite. While it's not a trivial task, the reward is definitely worth the work involved to get this working...

Incorporate a feature whereas each asset you want to have included in ANY navigation is assigned a unique ID. This ID number could be stored in a flat text file at worst and a database at best. The ID would identify the record and other attributes to this record could minimally be: parent content ID, content title, content URL, content section ID. You could build a relationship with the content section ID field, also.

Do you see where I'm going with this?

After you have several hundred entries in this text file, you have a TPL regen the component sidenav whenever a DCR of that category is edited.

Let me know if what I said was Greek or if you have questions, otherwise.

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

chuckles

Can you provide a litte more info? Most importantly, what kind of environment do you have set up? What kind of DB, web/app server do you have in your target environment? I have seen setups similar to what both you and Dave have described. Those seem to be the most popular approaches. A bespoke application for creating your navigation is also possible, but you probably want to leverage what you already have.

dkuntze

My current setup is:

TS 6.5 win2k
MSSQL 2k

The app server I'll be deploying to is IBM WebSphere (v 5) -- but my goal is to output just plain html files generated by TS.

hope that helps.

dkuntze

This sounds familar but I hadn't thought of storing it in a SQL db. I'm worried about the deletes mostly... I suppose there is some sort of event hadler for this(?).

Migrateduser

You lost me -- if we're talking about composing a navigation structure, what does this have to do with event handlers, which, if I'm not mistaken, is a Javascript/FormAPI thing? Honestly, I think storing it in a DB is ideal -- I used the flat file previously because I didn't have the availability of a database, but would have definitely used a DB for this if I had had one.

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

dkuntze

Let me clarify:

What happens if I delete a DCR? How does the nav data (in the database) get deleted too?

Darin Kuntze
Senior Programming Analyst
First National Bank Nebraska, Inc.

Migrateduser

I see... what we would do, without a database (but you can see how the capability of a database would be parallel to this), is to first of all, remove the native "Delete" function from the OOTB Teamsite GUI and build our own Custom UI which does the following:

1. Deleted the line containing the record from the flat file, or row from the database table.
2. Delete all child nodes from the flat file or database, relying on user education to know that there are no orphan nav objects.
3. Regenerate all nav elements for that section of the site, perhaps limiting it to those which are actually affected by the DCR deletion.

Does this answer your question?

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

dkuntze

It does. But since I'm a newb to TS it'll be a fun implementing this. Gotta learn it somehow...

What do you recommend for specifying the location of the nav elements in the DCT? ie. How to specify what level the nav is at... root, level 1, etc... In that same thought, how would you specify the parent nav element of a non-root nav element?

Darin Kuntze
Senior Programming Analyst
First National Bank Nebraska, Inc.

Migrateduser

Good questions. One of the restrictions of this type of nav building is that the parent elements' DCRs must be created prior to the childrens'. This is necessary because there can be no orphaned nav elements. There ARE ways around this, but I preferred to put a minor restriction on the users up front rather than creating a lot of work for myself.

I remember (and this is 3 years ago, now) that each record had 12 attributes. One of them was the level of the record, like you said, which was specified as 0,1,2, etc... the parent element was another attribute and was specified by its own ID. When an item was a root element, however, its level was 0 and its parent ID was also 0. You could argue that you don't really need the level attribute since you have the parent ID and can trace that back to determine the level of the nav element. But, there was little cost in collecting this information and performance and integrity were strengthened by the incorporation of this attribute.

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

dkuntze

Those are my thoughts exactly.

What sort of form elements would you use for selection of the parent navs -- taking into account that the depedent nature of each level. Using select boxes comes to mind first... but I'm not sure how to implement a solution where the next select box appears if a parent nav is selected. I suppose you could pre-populate a series of select boxes -- level 0, level 1, level 2, level 3 for example -- but this would limit the amount of levels that a person could use (which wouldn't be a bad thing now that I think about it).

Are there any other ways that you can think of?

Darin Kuntze
Senior Programming Analyst
First National Bank Nebraska, Inc.

Migrateduser

Well, you could dynamically populate the select boxes (in a callout). For instance, in your Level 1 select, you'd have something like "No Parent","Products","Services","About Us", for instance. When you select one of these, a second set of selections becomes available. Using Perl and Javascript together, you're able to prepopulate some Javascript arrays indefinitely and thus, have any number of levels represented in these dynamic drop-downs. As far as usability, I think this is probably the best option.

Fortunately, I had a community of very educated users and I was able to require them to simply enter the 5-digit document ID of the parent record. No one complained and it saved some development and testing time.

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

dkuntze

I'm not so lucky to have educated users here.

How do you make a second set of drop downs to appear in TS? I think I can populate them with a callout fairly easily... I'm just not sure how to get them to appear and increment the name by one each time: level0, level1, etc...

Darin Kuntze
Senior Programming Analyst
First National Bank Nebraska, Inc.

Migrateduser

Without getting too detailed, I was referring to the callout solution. In this case, you'd have a good amount of Javascript interacting with the user to create these drop-downs in the first place. By using properties such as object.innerHTML, you can cause items to appear and disappear dynamically. When the user gets to the terminal point, or they select something like "PUT MY DOC AT THIS LEVEL", you could have a JS function validate the form and iterate through the levels of drop-downs they just filled out. I'm thinking you would send two values back to the form: the level number (0..n) which you can get by iterating through the drop-downs and the parent ID, which can be retrieved in the same process and just as easily.

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

Migrateduser

You could use iwat to register a handler for the Delete event, but that would probably turn out to be a pain. The simpler approach to solving that problem would be to make sure that all your content publication/unpublication goes through a workflow and add/remove from the nav as appropriate.

Tim__D

I'm facing this same challenge in a current product. My parent child relationships for the navigation are all contained in a single DCR. This DCR contains 4 levels of nested replicants. Each item in each level of of the navigation DCR is assigned a unique ID via callout. Once the navigation is completed it provides the data to a callout used by other templates used to publish pages that have navigation. The callout allows them to choose where the page they are publishing "lives" within the sites IA. What they see is a indented nested list of navigation items similar an expanded left tree pane in Teamsite 5.5.2. When they click the link the value returned is a dot delimited list of navigation IDs which are all unique keys for the context of level 1 level 2 level 3 level 4. Example: 20050613161456830.20050613161508236.20050622035830944.20050801205127693

At this point the page knows where it lives and the tpl's do the rest.

The challenge I'm facing is how to automate the regens when the thing changes or gets updated? Also some of the pages that use this feature may need to appear in multiple contexts within the site and because the navigation context value is saved as part of the DCR its impossible to share the content of any DCR that has a saved navigation value in multiple website contexts.

- Tim

Edited by Tim__D on 08/03/05 09:51 AM (server time).

Migrateduser

That sounds sort of similar to what I was referring to in the post to which you had hit "REPLY" (I think), but are you storing this information anywhere other than in the DCR? In my opinion, you should be. Otherwise, how would you regen the navigation when the structure changes? I believe that's the question you're asking.

What I had done is to store the heirarchical / navigational information in a flat file (not ideal, but I didn't have a database available to me at the time). When a new asset is added, a script kicks off that regenerates the navigation structures that relates to it, if necessary. This is determined programmatically. In each generated file, the navigation structures were actually included shtml files, so that part was easy enough. So, when the script repaints the navigation, it should show up in TeamSite, be deployed, and eventually to the user (browser or server caching notwithstanding).

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

gzevin

Just to add to Dave's comment. In addition to the approach of using SSIs (I also have developed such a technique some 3 years ago and it's been used in dozens of sites by now) I could just say that the updates of the nav are done via specific workflow that updates all relevant workareas at the time anything has been changed.

I don't see much challenge in tackling what has been described above..

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Tim__D

In my implementation there are no SSI's for the navigation. If the navigation changes every page needs to be regenerated and will be changed. The reson for this is that the navigation is truely unique for each page on the site.

Migrateduser

That was my situation, as well (every navigation was unique). So, if document #41002 went through, for instance, then nav #41002 was created. If this document's navigation changed, then only the navigation components related to 41002 and itself were changed. I think I remember there were concurrency concerns with changing the entire file versus just the navigation component.

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Tim__D

So in my case what would you suggest.

1). User saves NAV DCR
2). External task run to regenerate all pages in the branch?

Migrateduser

Is a nav DCR even necessary, though? Could you instead just store the relationships somewhere and have the externaltask regen all related navs when necessary? This setup also requires that the user specify (dynamic drop-down lists or what have you) where the DCR lives with respect to the navigation. This way, you have enough information to build the nav programmatically.

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

LooseCannon

instead of updating every html page you could simple update one javascript file that prints out the nav client side

Migrateduser

That would be a very nice idea for a smaller nav structure, but what if the navigation is very complex with a thousand or more possible items? Then, you have these large JS arrays loaded into every page. That seems like a lot to push on the user. Besides, my suggestion (and I think Greg's) is to programmatically regen only the affected nav files which might be 8 - 10 or so. Granted, this puts a bit more strain on the TS server to regen these files than simply printing out / changing some JS code, but it's only an externaltask and a TS server should be able to handle regenning many files at once.

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Tim__D

For me the DCR provides a parent child relational structure up to 4 levels deep. Because it's a DCR it also provides acess via FormsPublisher. The model is to create the structure then share the structure with other pages which know where within the structure they reside. I am having a hard time visualizing how the flat file or SSI solution also provide these features. Thanks for your thoughts and interest in this topic. I'd like to discuss more. Another thought I had was using meta data but my experience with this is small and the lines between it and using EA's (which I dont use because they cant be merged) are blurry.

- Tim

Edited by Tim__D on 08/04/05 01:05 PM (server time).

querychange.rptdesign