So... we could just grab that from the nav manager then. It might work. All of our subsites will be linked through a master link called "Offices and Services" You can see it here: http://www.gsu.edu/offices_services.html. So a subsite would appear here: http://www.gsu.edu/es/
If everything is set up like that, I could grab the department name by grabbing the name of the page whose parent is "Offices and Services" right? Would that pull the site map name or the actual page name? BTW, where are all of the navigation manager tags documented? Dave On Oct 23, 2:39 pm, Irina <[EMAIL PROTECTED]> wrote: > Not sure what your navigation structure is, but you can get the > department value from the Context and your Path Array: > <%!! Context:CurrentIndex.GetPathArrray()[Int:1].Headline !!%> > > Another option is to have opt_Department variable on each page, and > make users to assign it every time when the new page is created. > > Irina > > On Oct 23, 1:23 pm, Dave R <[EMAIL PROTECTED]> wrote: > > > Ok, that makes a bit more sense. > > > The question is... how do you trigger those pages to grab the right > > department info? Would you have to do it off the navigation manager > > somehow? It just seems to me that if you do something like that if you > > move the subsite to another location, that department flag will change > > as well. > > > On Oct 23, 12:02 pm, "Smith Paul \(SLH\)" <[EMAIL PROTECTED]> > > wrote: > > > > I think what Irina was trying to suggest was the creation of some little > > > pre-executing scripts in your foundation page to allow you to show/hide > > > parts of your page based upon some variables. This doesn't involve > > > creating multiple foundation pages, just a little bit of careful planning. > > > > These could be standard text fields within the page, allowing for a > > > default value in each child site. Alternatively you could replace the stf > > > with a variable and create a separate file where you set values for each > > > variable and include it into the head of each page. This second option > > > would then allow you to set the values for each site in once place. > > > > We've got something similar to allow us to have multiple layouts with one > > > foundation page and it works well. We've also using the config file > > > approach to allow us to easily manage things like Webtrends and > > > GoogleAnalytics IDs for each child site > > > > Paul > > > > -----Original Message----- > > > From: [email protected] [mailto:[EMAIL PROTECTED] On > > > Behalf Of Dave R > > > Sent: Thu, October 23,2008 15:51 > > > To: RedDot CMS Users > > > Subject: Re: Just moved to 7.5: Trimming Foundations down to 1 with > > > multiple subsites > > > > OK, well... here's where you are loosing me. > > > > 1) We want one foundation and we want to use the navigation manager > > > and not target containers. > > > 2) By creating an instance of that foundation for each department, we > > > would be doing the same thing we are now and would still need to use > > > target containers. > > > 3) If we did use the navigation manager and killed the target > > > containers, we would have to manually put in the department name/ > > > fields with each page in the site we create with that foundation. > > > > What am I missing here? It just seems to me that I can't set that > > > standard field dynamically with a page definition. > > > > Dave > > > > On Oct 23, 9:26 am, Irina <[EMAIL PROTECTED]> wrote: > > > > Hey, > > > > > Your solution will be one foundation template with some pre-executed > > > > script to display custom elements. An instance of the foundation page > > > > will be created for each department, or for each subsite. > > > > > 1. Create one re-usable foundation page. Add placeholder called > > > > stf_Department (or opt_Department) > > > > 2. Create instance of the foundation page for each department. Assign > > > > stf_Department value for each instance > > > > 3. Add pre-executed script around each custom block. Example > > > > <% > > > > if <%stf_Department%> = "Department One" Then > > > > %> > > > > //display navigation list and navigation image for About Us section > > > > <%img_DepartmentOne%> > > > > <%lst_DepartmentOne%> ... > > > > > <%End if %> > > > > Most likely it will be a case statement based on all possible values > > > > of stf_Department > > > > > Note that you can also use transfer element to pass standard field > > > > from a page in a target container to a foundation page. > > > > > Hope it helps, > > > > Irina > > > > CGI RedDot Team > > > > > On Oct 22, 11:49 am, Dave R <[EMAIL PROTECTED]> wrote: > > > > > > Hey, > > > > > I'm with Georgia State University. We've been using RedDot CMS now > > > > > since about 2005 and I just found out about this group. I apologize, > > > > > but this is going to be a long first post with a couple of questions > > > > > introduced throughout. > > > > > > We're about to embark on our first major redesign since then and with > > > > > 7.5 we will want to make the most out of the navigation manager and > > > > > page definitions. One of the main problems we're having at the moment > > > > > is how do we build a single foundation that works for every thing. Let > > > > > me give you a few examples: > > > > > > Our Current Homepage:http://www.gsu.edu/ > > > > > The main nav is currently the top nav bar. The left nav is more user/ > > > > > informational specific. Everything there should have a main home under > > > > > the top nav. With the redesign, we'll make this arrangement more > > > > > clear. > > > > > > A Current Subsite:http://www.gsu.edu/es/ > > > > > A major point of concern is getting the graphic banner for the > > > > > department (right under the horizontal nav) worked into the foundation > > > > > without creating a new foundation. Another issue is ensuring that only > > > > > the navigation for that subsite shows in the left. All subsites right > > > > > now run through the Offices & Services link in the top navbar and > > > > > that's reflected in the breadcrumbing. I'm thinking this is easy if we > > > > > have our logic right for the navigation manager. > > > > > > Another thing to know is that everything right now is of course build > > > > > using target containers. > > > > > > So, the question at this point really is: How do we build a foundation > > > > > that will have the potential to display custom elements without having > > > > > to create a new foundation? What's the best practice here? > > > > > > The next thing is what we are looking at in the future. We recently > > > > > did have to create a new template for our Undergraduate Admissions > > > > > group. They didn't have the time to wait for the full redesign and we > > > > > wanted to test some things out. The version of the site that is live > > > > > has been built using RD 6.5 not 7.5 and is target container based. We > > > > > have several elements that are only used on certain pages such as a > > > > > left navbar and a flash banner. > > > > > > So, the question here again is: How do we build a foundation that will > > > > > have the potential to display custom elements without having to create > > > > > a new foundation? > > > > > > This design is very close to what we hope will go live, but the > > > > > marketing/design group hasn't actually designed it yet. This is solely > > > > > based on the wireframe we think will resolve our biggest problems. > > > > > > Here's the site: > > > > > Main Home:http://www.gsu.edu/admissions/ > > > > > Audience Home:http://www.gsu.edu/admissions/highschoolindex.html > > > > > Basic Page:http://www.gsu.edu/admissions/28285.html > > > > > > I'm not so much worried about inserting a photo at the top of the > > > > > page. That can be handled through various content classes within the > > > > > content area. It's the fact that some pages will not require a left > > > > > navigation bar or flash banner which will always be above the top > > > > > navigation. Then there's that whole navigation problem itself. > > > > > > How would you all handle these issues? We have well over 30 subsites > > > > > that will need to be rebuild/redesigned with the new template so this > > > > > is very important. > > > > -------------------------------------------------------- > > > > UCB Celltech is the UK branch of UCB Pharma S.A., a company registered in > > > Belgium with registered offices at Allée de la Recherche 60, 1070 > > > Brussels, Belgium, KBO/BCE nr. 0403.096.168, RPR/RPM Brussels. > > > UCB Celltech's UK branch registration number is BR009137 and its UK > > > representative office is at 208 Bath Road, Slough, Berkshire SL1 3WE. > > > -------------------------------------------------------- > > > > Legal Notice: This electronic mail and its attachments are intended > > > solely for the person(s) to whom they are addressed and contain > > > information which is confidential or otherwise protected from disclosure, > > > except for the purpose for which they are intended. Dissemination, > > > distribution, or reproduction by anyone other than the intended > > > recipients is prohibited and may be illegal. If you are not an intended > > > recipient, please immediately inform the sender and return the electronic > > > mail and its attachments and destroy any copies which may be in your > > > possession. UCB screens electronic mails for viruses but does not warrant > > > that this electronic mail is free of any viruses. UCB accepts no > > > liability for any damage caused by any virus transmitted by this > > > electronic mail. (Ref: #*CUK0308) > > > --------------------------------------------------------- Hide quoted > > > text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/RedDot-CMS-Users?hl=en -~----------~----~----~----~------~----~------~--~---
