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

Suggest a scalable solution for DCT

dolly1

Hi All,
We are using Teamsite 7.2 and will be upgrading to 7.3.1 soon.

Currently we are in the process of redesigning the DCTs. As of now our DCTs are like containing some textarea to enter the complete HTML blocks for the page.

Now, in order to redesign we have done some analysis and figured our some layout containers then content modules based on the different types of pages which we have. For example: A 3 column container, A 2 column container etc. Now these containers can have some content modules like Para, Image, Video etc. Like this we have some 7-8 layout containers then around 20 content modules as of now.

These layout containers and content modules are created as a separate XML and then included in the main DCT. Content modules are reusable in layout containers.

When we create DCT which is having all layout containers, each layout container containing content modules then DCT becomes very heavy.

Though we can limit some content modules that can lie in each layout container still this solution does not seem scalable. At a time I was getting out of memory error while doing a new form entry now it is better still we are looking out for an efficient solution and which does not cause performance issues later when we add more layout containers and content modules.

Any suggestions on a better approach is appreciated. Looking for an early response.

Thanks in advance.

Find more posts tagged with

Comments

dolly1

Any suggestions on this? Anyone??

Adam Stoller

The somewhat obvious suggestion, based on talk about n-column layouts, is that you should probably be looking at SitePublisher (with or without LiveSite) and simplify your DCTs / DCRs to be component-speicific content modules rather than complete pages.

If you want to stick with the DCT / DCR per page structure (one I happen to actually like, but then again I haven't really done a lot with SP/LS - so it's "old-school" bias) - you need to figure out if your performance issues are due to the number of options you are making available, or the types of elements within those options (i.e.: is the problem that you offer 50 different types of 'items' to go in an OR container or that you allow 50 WYSIWYG textareas to appear within a single DCT?)

You're generally better off making DCTs as specific as possible rather than trying to make them so generalized that they become completely unwieldy and a nightmare to maintain. Re-use is a good thing, but over-generalizing the concept can lead to problems.

Bowker

I agree with Fish's recommendation. Although I'm a convert to components from the one mega template (sorry Fish).

Our paradigm (SitePublisher w/LiveSite Display Services) is something like:

1) "General Resource Content" DCT with three main fields
a) Parent Page Description - used as a short description that can be put on the right side of another page as a "related page" tease.
b) "Desktop content" - used for the main content
c) "Mobile content" - if the business wants to have different text (maybe different images/formatting etc...) for the mobile site they fill this in, otherwise the Desktop Content is used.

2) "General Resource Presentation" Component that displays the proper content field.

3) "Learnmore" Component for the right side tease that utilizes the Parent Page Description of the same DCT.

As long as the content doesn't change LiveSite can cache the presentation which results is VERY fast response. We've found that the response time is sub second.

dolly1

Thanks for the reply. We did analyze Sitepublisher approach at first which can solve these issues and flexible as well but due to effort constrainst this was rejected. Smiley Sad

As of now we do not use site publisher and livesite, so moving to site publisher means:

1. Setting up sites, layouts, templates
2. Creating components
3. Creating pages
4. If not using livesite then need to integrate these pages with existing JSP
5. Setting up deployment to app server as pages, layout CSS need to lie here
6. etc

This was lot of effort compare to only redesign the DCT hence it was not accepted.

RonaldV

If your dct becomes to complex you will have to move to a simpler dct concept. Both for your end-user: (s)he will have a hard time understanding a dct with multiple columns/rows/modules, etc.

And for your PC because a complex dct becomes heavy in terms of javascript processing power (as you have found out).

How you simplify your dct is a matter of requirements, users, etc. I don't think an simple answer will suffice. 1 idea might be to create separate dct for your modules (like para, image, etc) and then include these in your page-dcr. But this can create new problems in terms of broken links to deleted module-dcrs, etc.

dolly1

Thanks Ronald. We are actually now considering the same approach what you mentioned.

Creating different DCTs for column containers or modules (one of these).

One issue which we face is when from master DCR a new child DCT form is opened, we are trying to save the child DCR path back again in master DCR text field.

Used something like below in the master DCT:

< item name="paragraph_module" pathid="paragraph_module" >
< label > Generic Paragraph< /label >
< text required="t" >
< callout label="Manage Paragraph" url="/iw-cc/newform?vpath=WA path &iw_tdt=dct category/datatype"/ >
< /text >
< /item >

and when try to use the traditional window.opener.top.getScriptFrame(); to get the field name of the master DCT it says window.opener is null. We have used the same in other callout which open JSPs etc but never with a new form entry and not sure if it will work. Any idea what is missed here?

Another issue is, we need an item handler for this callout to see if the field in master DCT is already polulated with DCR path then open the same DCR in edit mode. Now here the issue is:

We have multiple around 7-8 column containers then each can have around 20 modules so it is becoming around 140 XPATH combinations to define the item handlers for. This will definitely be not acceptable. Any suggestions on this one as well??

dolly1

Any idea, anyone?? Why window.opener does not work in case of new form entry from a master DCR.

Adam Stoller

Any idea, anyone?? Why window.opener does not work in case of new form entry from a master DCR.

Try

parent.window.opener

perhaps?