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

CC Standard users and DCRs

System

Hi Devnetters -
I'm working through my first fully templated site design in FormsPublisher, with a current emphasis on understanding the business user experience. Initially, I'd like to set this up as generically as possible.

With that in mind, my question is: what types of problems do CCS users have with managing DCRs? In pretending that I'm a CCS author, I've found that I can do things like:
- Create a DCR and then invoke workflow on it without ever generating an .html page out of it,
- Open up a DCR by surfing the virtualized site, do a 'Save As' to another DCR name and then when I hit Generate, it regenerates the original .html file I started from instead of seeing the DCR as new and prompting me for a new output file.

I'm sure there're more, but these are a couple of ways I can predict getting support calls if I roll this out as is.

Do the users understand and get used to dealing with DCRs and performing the generate function? I don't think I can proceed with that assumption, so I'm looking for suggestions to make this site more bulletproof.

Thanks,
Wally Box
Nike, Inc.

Find more posts tagged with

Comments

Adam Stoller

Well... one problem with CCS (as opposed to CCP) is that there is no context for the workflows - i.e. when you initiate a workflow it isn't being started from a particular workarea on a particular branch - so you need to prompt for that information if you cannot otherwise determine it from pre-selected files (haven't tried this, but it *might* work - I tend to prefer CCP).

Once you get past that - my general advice is to automate page generation as much as possible - which means disable Generate from the DCT forms, have either a 1:1 relationship between DCT and PT or make sure there's something within (or in an EA attached to) the DCR that will allow you to programmatically determine what PT to use; Also - use sub-directories under data/ to mirror the location of the to-be-generated page and derived the name of the generated page from the name of the DCR (e.g. workarea-name/..../data/foo/bar/baz/mumble.dcr => workarea-name/foo/bar/baz/mumble.html); this relationship between directories should be maintained through to the web or application server where you'll be deploying the assets (replace workarea-name with doc_root in previous example).

So - the basic idea is to have content creation and content submission managed by the workflows -- for creation purposes you can use a cgitask to prompt for the name/location of the DCR and then create a dummy DCR for that type and have them edit it -- after that it's a matter of reviews, page generation, submitting to staging and deploying.

That's my feeling anyway.

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

Migrateduser

It depends on what sort of workflow. There isn't, by default, any way to start a New Job workflow from CCSTD (at least not that I've noticed), so you would have to add your own module for new job workflows, in which case, I would expect the problem you describe to obtain. For submit workflows, there's no problem. iw_workarea will automatically pre-populate with the proper value as you can see from this snippet of the source of the instantiation page.


<input type="hidden" name="iw_workarea" value="/default/main/Intranet/TSG/WORKAREA/content" >

iwovGraduate

There isn't, by default, any way to start a New Job workflow from CCSTD

There is a link to New Job in TS 6.1 on the CC Std main page.
However (as mentioned earlier) since CCStd does not have context of workarea, your workflow needs to prompt the user for area.

One workaround we did in the past was to disable the New Job link from the CCStd main page and include a New Job link in the "browse" workarea page - which will have a workarea context.

Migrateduser

DOH!!

I never noticed it hiding over there in the upper right hand corner. Hmmm, sort of makes one wish that there were documentation for the new interface.

Migrateduser

Fish -
You're a wealth of information, thanks. You've more or less confirmed my feeling that there's really not a simple, foolproof combination of FormsPublisher and workflow that can prevent the types of potential problems I listed above. I'll have to go to the next level of design to make it happen.

I do like the idea of keeping the /data directory structure the same as the published sites'. I'll have to look more into how that would happen. I'm not sure that the cgi task for defining where a new page would work - that implies a workflow, which I wouldn't be in until they're finished their edting.

Wally Box
Nike, Inc.

Solito

Can you please detail the solution as we are having this issue ..?
thanks

iwovGraduate

Look at the UI Customization guide. That will get you started on how to remove/add links, etc.
Hope that helps.

Solito

that helped ...thx