Hi Joel, The having no more than "X" number of elements on a page tale originates from the project report that one can generate from the Project node of a project. The mystical number "X" is actually not true. You can have as many elements in a content class as you want to, BUT here is the performance drawback:
Let say I have a content class with 1 element, and there are 100 page instances, the project data base will have 1x100=100 database rows. Let say I have a content class with 3 element, and there are 100 page instances, the project data base will have 3x100=300 database rows. As you can see, the scaling of project database is proportionate to number of pages times number of elements page page. Going to switch gears a little to the navigation area issue. Using your sample code, loading the navigation area to get configuration back cost the CMS to look up a navigation area, loading current page object, load parent page object, load parent page element object. That is 4 units of work per page. 4x100 pages = 400 units of work for the entire site. When a user previews a page, is it faster to do 4 units of work or search through 300 database rows? When a full site publish happens, is it faster to do 4 unites of work while the system is MAXED with 400 page objects or search through 300 database rows? Sorry, I cannot give a scentific or subjective answer as there are many other factors that determine the speed of a project. However, on a project that was previously using the navigation config approach, I have changed it to use the element reference approach (more elements per page), and pages still load a second or 2 faster on single page load, and full site publishing is at least 20% faster. -Jian On Friday, August 23, 2013 11:49:53 AM UTC-4, Joel Kinzel wrote: > > Okay, so the other item we often hear about is not to have more than "X" > number of elements on a page. I'm curious if you've done any testing as to > which is more resource intensive: Have a lot of elements on a page or > having many navigation areas? > > My initial thought would be the elements, because AFAIK the navigation > areas are cached. Thoughts? > > > On Monday, August 19, 2013 7:51:12 AM UTC-5, Jian Huang wrote: >> >> The solution I have implemented is as follows: >> >> 1. still have a configuration page, it is just not located as the first >> page of the project structure. I usually have it like this >> >> Start Page >> anc_dyn_link >> Home Page >> anc_dyn_link >> Technical Administration Page >> anc_dyn_link >> CSS >> anc_dyn_link >> JS >> anc_dyn_link >> Project Configuration Page >> >> Instead of using rendertag or navigation area to get an element value >> from the project configuration page, I just create an element on the page, >> and reference the element to the element on the project configuration >> page. This way, should the user desire to have different value for the >> element on the page, they can severe the reference, and enter independent >> value. >> >> I also wrote a plugin can retro active ELEMENT reference to do this >> retroactively on projects that were using rendertag/navigation area, to >> help them switch to the element reference method. >> >> -Jian >> >> >> On Friday, August 16, 2013 4:27:04 PM UTC-4, Joel Kinzel wrote: >>> >>> Yeah we don't have the TOC in navigation. We just use navigation areas >>> to pull the settings from it. In order to have multiple sites in the same >>> project, we need a way to have multiple settings pages as well. We found >>> nav areas to be the "best" solution If you have another idea, I'm all ears. >>> >>> On Thursday, August 15, 2013 10:00:40 AM UTC-5, Jian Huang wrote: >>>> >>>> Hi Joel, >>>> >>>> The config page is something from the Best Practice Project. Well, the >>>> practice of having the config page actually produces some issues. >>>> >>>> 1. The root node of the site navigation should really start at the >>>> Home Page, not the TOC page because then extra navigation template and >>>> processing are needed just to SKIP level 1. You can still have a config >>>> page by access it via Pages.GetPage(). >>>> >>>> I don't know enough about your project, but it is possible to use >>>> con_translateCode to reference a page that contains txt_translateCode? No >>>> navigation or rendertag is used. Simple project and easy maintenance. >>>> >>>> On Thursday, August 15, 2013 9:41:10 AM UTC-4, Joel Kinzel wrote: >>>>> >>>>> We have a very distributed environment, so keep that in mind when you >>>>> read my solution. >>>>> >>>>> >>>>> We have a "Table of Contents" page for each site in the CMS. On that >>>>> page we allow users to enter site-wide information and settings (column >>>>> alignment, breadcrumbs, taglines, search settings, translate, and >>>>> others). >>>>> In order to use Google Translate you need to generate unique code for >>>>> each >>>>> site. We have instructions for our users on how to do that. >>>>> >>>>> On the table of contents page, we then have a text area with >>>>> "Deactivate text filter", ASCII Text", and "Do not convert characters to >>>>> HTML" checked. This essentially gives the user an extremely stripped down >>>>> editor. We ask them to paste the code snippet into that text area. We >>>>> have >>>>> another one for the meta tag that is required. >>>>> >>>>> We then have a navigation template that looks something like this: >>>>> <%!! >>>>> Context:CurrentPage.MainLink.OwnerPage.GetElementByName(txt_translateCode).Value >>>>> >>>>> !!%> >>>>> >>>>> The area is set to Level 1-1, Selected Only (this allows multi-site >>>>> projects with unique settings) >>>>> >>>>> Then on each page, we just render that navigation area. >>>>> >>>>> Is it ideal? No, but it works for us! >>>>> >>>>> >>>>> On Wednesday, October 27, 2010 11:45:24 AM UTC-5, psreddy wrote: >>>>>> >>>>>> Does any one implemented google translate in Reddot for the website?. >>>>>> Please let me know your suggestions >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/reddot-cms-users. For more options, visit https://groups.google.com/groups/opt_out.
