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

TeamSite "best practices" question

Lex

We're currently running TS 6.5 SP2 on Win2K3. Here is the situation I'm looking for input on:

We have a branch called "enews". This branch was created for generic e-newsletters that various lines of business will be creating to send to external customers (opt-in lists; this isn't spam! Smiley Happy

). A workarea was created, a DCT and TPL developed, and all of this is presented through our company portal (Plumtree) via a portlet I wrote using .Net and the CSSDK 2.0. When a user creates a new e-newsletter they are presented with the DCT, they fill it out, save it, and it's automatically submitted to a workflow which generates the HTML, places the resulting HTML on a server where Microsoft's Commerce Server picks it up to email out to the external customers. That's all there is to the workflow - they didn't want any approval steps or anything like that so it's dead simple.

When we originally set this up only one line of business was interested - Fine Paper. OK, so far so good. Now other lines of business are looking at sending out e-newsletters. The various lines of business don't want to see each other's e-newsletters so somehow we need to separate these out.

As I see it, we have a few options for how to do this and I'd like to elicit some input on which option would be best. Also, if there are other ways I should be looking at approaching this I'd be interested to hear them.

1) Create a separate workarea for each line of business. I hesitate to do this because I believe (I'm more of a TS developer than a TS administrator) that this would require maintaining the DCT and TPL in each of these workareas we create. I'd like to keep maintenance centralized if possible.

2) When displaying the existing e-newsletters in the portlet, filter out the e-newsletters by User ID. If I go with the User ID that created the e-newsletter I kill collaboration because a user will only see their e-newsletters and not those created by other members of their team.

3) When displaying the existing e-newsletters in the portlet, filter out the e-newsletters by group. If I go with a group, how do I assign this group to the DCRs created? I can see in the properties of a DCR that there is a group, but it's always empty. If I could somehow assign the group that the user belongs to at the time of creation, I could easily filter on this for display in the portal.

Any thoughts, ideas, critiques would be appreciated. Thanks!

Darryl Luther
darryl.luther@weyerhaeuser.com
Senior Web Analyst
Weyerhaeuser

Find more posts tagged with

Comments

Adam Stoller

1) Create a separate workarea for each line of business. I hesitate to do this because I believe (I'm more of a TS developer than a TS administrator) that this would require maintaining the DCT and TPL in each of these workareas we create. I'd like to keep maintenance centralized if possible.

Uhm - if you're using different workareas on the same branch - and you are versioning your DCTs and PTs (which you should!) - all workareas on that branch will see the same DCT and PT - no extra maintenance involved.

Perhaps add a field to the DCT to indicate which business / organization e-newsletter is being created and provide a filter in your portal to select which business('s) / organization('s) e-newsletters to display?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Lex

I guess I have a basic lack of understanding behind multiple workareas (we've never set thing up that way here, instead opting for a single shared workarea). Once we create separate workareas for each line of business, would we then make any updates to the DCT and/or PT in the "enews" workarea, submit these changes to staging, and simply "Get Latest" in each of the line of business workareas? Do most people set up a workflow for this and automate the process of "Get Latest" in each of the workareas?

Darryl Luther
darryl.luther@weyerhaeuser.com
Senior Web Analyst
Weyerhaeuser

crosstabgroupheader.rptdesign

ineedgroupHeader like.txt

Adam Stoller

Once we create separate workareas for each line of business, would we then make any updates to the DCT and/or PT in the "enews" workarea, submit these changes to staging, and simply "Get Latest" in each of the line of business workareas?

Yup.

Do most people set up a workflow for this and automate the process of "Get Latest" in each of the workareas?

It depends - this is one of those "gray areas" in which "most people" is a very subjective phrase.
There are any number of ways of dealing with this synchronization - workflow is one, custom menu item is another, manual process is yet another. I suppose you could handle it via iwat triggers too. It's more a question of how *you* (or your organization) believes that things should be set up to work.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Adam Stoller

Also ... you generally want to be careful about making changes to the DCT after it's been in use. Adding fields generally isn't a problem. Removing fields will lose the data associated with those fields the next time a DCR is edited and saved. Changing the *structure* of the DCT (moving existing fields in/out of containers and such) is something which you generally want to avoid if at all possible because it would require you to make the same change to all pre-existing DCRs.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

crosstabgroupheader.rptdesign

reddyl

I think you should follow a naming convention for the DCR's and generated files, two business units can use the same name.

Adam Stoller

I would suggest distinct sub-directories under data/ and thus under the workarea-root (and thus under the web-site doc_root) to distinguish one business unit's files from another's

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

mike_jaixen

We've tried to standardize most of our templates so that DCR's are very similar across each branch. Then, we have build reusable components that are stored in a master branch, and then refer to them with an <iw_include pt="/.iwmnt/default/main/master_template_branch/STAGING/templatedata/component.tpl" mode="cwd"/>. This way, each section of the site can be in it's own branch, but share most of the presentation templates. The .tpl file underneath the presentation folder for each template, in the end, becomes an HTML wrapper that is only about 30 lines long, intermixing the basic HTML components framework <html><head></head><body></body></html> with a series of includes to actually build the page.