Home → How Do I... →

Index Block with Parent's siblings

• Edit

birwin

09 Mar, 2015 06:55 PM

Hi there, quick question to see if I am able to do something

Our website uses a bit of an unusual navigation system - which I am trying to optimize. Currently we use a index block which indexes the whole site - and looks at the base folder "/" as the Index folder. I know - bad!

So what I am attempting to do is make the navigation more focused around the current asset - eg the navigation uses an index block with no index folder specified so it looks at the current asset's folder. That part works ok - and provides a large speed hike, now here is the tricky part, I've been requested to create two types of Navigation:

1) Start navigation here
2) Show site's traditional Navigation

For #1 - that was simple, just make the index block Render normally at the indexed folder. Bam Done. For #2 - this is where I need a little help (if its possible to do so)

I'd like to get rid of the site-hierarchy block which indexes the whole site, and replace it with an index block which indexes the current asset. I need it however to not only index the current page with folder hierarchy (because I need to know the parent folder) but I need to know the parent's folder's children.

I guess a Better word would be I need to know the sibling folder's pages . The reason for this is to check if they have an index page because I only want to render sibling folders if they have that index page.

Example

Folder Tree:
A(folder)
B(folder)
+D(B's Child > Folder)
+E(B's Child > Folder)
--E's Child > index Page
+F(B's Child > Folder)
-h(B's child > index Page)
C(folder)

So in the not so great diagram above, assuming I'm on "E's Child Page" I'd need to be able to look at the index block and see if Folders (D,F) have a page in them named index)

I've tried the "Start at current Page with folder Hierarchy, siblings, and also render forward" which I'd assume would have it but, not having luck. Is what I'm doing possible - or will I have to stick with using some sort of index block on a parent item

Many thanks!

Brendon

1. 1 Posted by Ryan Griffith on 09 Mar, 2015 08:00 PM

   

   Hi Brendon,

   As you encountered, the option to Start at current Page with folder Hierarchy, siblings, and also render forward will render forward based on the context page, so you won't be able to go up a level to the parent folder and then traverse down into it's child folders (that are not the current folder).

   If you are comfortable with Velocity and the Locator Tool, you could use a hybrid approach where you use the Start at the current page with folder hierarchy, and also include siblings option to obtain the hierarchy and then use the sibling path and Locator Tool to attempt to locate an index page. Consider the following example:

   #foreach ($child in $children)
     #if ($child.getName("system-folder"))
       #set ($folderPath = $child.getChild("path").value)
       #set ($indexPage = $_.locatePage("${folderPath}/index", $currentPage.siteName))
       #if (!$_PropertyTool.isNull($indexPage))
         ## We found an index page.
       #end
     #end
   #end
   

   It might be a little bit of extra work, but I suspect this should help with overall rendering since you are still avoiding indexing your entire Site.

   Please let me know if you have any questions.

   Thanks!

   • Edit

2. 2 Posted by birwin on 09 Mar, 2015 08:01 PM

   

   That's gorgeous - I'll give it a go, and let you know how it goes

   Thank you!

   • Edit

3. 3 Posted by Ryan Griffith on 09 Mar, 2015 08:13 PM

   

   Not a problem at all, Brendon. It's not the most elegant solution, but I think it might be worth a shot to see if it is a decent compromise for what you are looking for.

   Please keep me posted on how things work out and let me know if you have any questions.

   Thanks!

   • Edit

4. 4 Posted by birwin on 10 Mar, 2015 02:27 PM

   

   Hi Ryan - I do have a question - I'm about to try what you suggested above, but was wondering, behind the scenes, how does the locater tool locate pages - is it more efficient than using a site-wide index block? Does it query against Cascade's internal database or something different?

   One other side question is, (and I'm experimenting with some things here) - if I have a block, which contains sub blocks eg:

   Nav Block
   -index block (current page data)
   -index block (site hierarchy)
   -index block (current page and folder hierarchy plus siblings)

   and my velocity format reads the first block to see which block (2nd/3rd) to access for it's data source (eg does it need the site hierarchy or does it just need a smaller index block) does this increase or decrease performance?

   I guess what I'm asking is, internally when the velocity script run, does cascade query the blocks regardless of whether they're being used, or only if they're needed for the script. I just finished playing with this way of doing things and couldn't tell.

   I know by switching out the site-hierarchy block with a reduced index block it sped up the page by 50%

   Im pretty comfortable with Velocity, I much prefer it over the XSLT alternative, and I think my argument of using it for our site is gaining more and more traction because some things that are just so much easier in Velocity are downright difficult and not easily maintainable in XSLT.

   Thanks for everything thus far,

   Brendon

   • Edit

5. 5 Posted by Ryan Griffith on 10 Mar, 2015 02:42 PM

   

   Hi Brendon,

   I'm about to try what you suggested above, but was wondering, behind the scenes, how does the locater tool locate pages - is it more efficient than using a site-wide index block? Does it query against Cascade's internal database or something different?

   The Locator Tool uses our Cascade API, which does technically access the database directly.

   We have a short summary that describes performance using Locator Tool vs Index Block on the Velocity Formats page in our Knowledge base (see the Locator Tool and Performance section).

   To summarize, performance really depends on usage. A cached Index Block will generally be much faster for looking up assets; however, if you require a giant Index Block just to get a handful of specific assets, the Locator Tool should be quicker. The hybrid approach I mentioned should be pretty quick, because it uses the Index Block to do most of the heavy lifting in terms of the folder hierarchy and then the Locator Tool to read a couple of assets. If you were to use 100% Locator Tool, this Format would probably be pretty slow since you will end up performing more read operations.

   I guess what I'm asking is, internally when the velocity script run, does cascade query the blocks regardless of whether they're being used, or only if they're needed for the script. I just finished playing with this way of doing things and couldn't tell.

   The Index Block would render with all of those Index Blocks regardless, so you most likely won't want to do this. Additionally, there are a couple of known defects relating to nested Index Block renderings being cached with incorrect data, so you might see some inconsistent results.

   Please let me know if you have any questions.

   Thanks!

   • Edit

6. Ryan Griffith closed this discussion on 17 Mar, 2015 07:01 PM.