Locator Tool and Index Blocks
Below is the code I am using to access an index block and the properties I get back. It appears that there isn't a way to find the list of indexed content from an index block. Is this correct, or am I missing something?
#set($profilePhotos = $_.locateBlock("/_blocks/hidden/Profile Photos", $currentPageSiteName))
$_PropertyTool.outputProperties($profilePhotos)
Object type: com.hannonhill.cascade.api.adapters.IndexBlockAPIAdapter
Properties:
- lastModified: Date
- identifer: Identifier
- identifier: PathIdentifier
- parentFolder: Folder
- path: String
- isUserCanWrite(String): boolean
- lastModifiedBy: String
- currentUserCanRead: boolean
- currentUserCanWrite: boolean
- isUserCanRead(String): boolean
- createdOn: Date
- hideSystemName: boolean
- siteName: String
- metadata: Metadata
- siteId: String
- folderOrder: int
- name: String
- parentFolderIdentifier: PathIdentifier
- createdBy: String
A little bit about what we are doing. We have facstaff profile pages in every site. There are also images uploaded in those sites for those profiles. We are using an index block to gather all the images together, and this index block is attached to each profile page. We use a custom metadata field to match the image with the page. This has been working fairly well, but when building department listings, it is rather slow due to calling the same index block for every page. The department listing index block ends up having 30+ copies of the image index block content, and thus runs rather slowly.
I would like to rewrite everything to use the locator tool to get the images index block, preventing it from needing to be in the page data definition, and thus trimming down the department listing index block.
I would be open to alternatives that allow me to build the same list of images as the index block would using the locator tool if it would be fast enough (find all files in a given folder).
Discussions are closed to public comments.
If you need help with Cascade CMS please
start a new discussion.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
1 Posted by Ryan Griffith on 27 Feb, 2014 03:58 PM
Hi Justin,
You are correct in that the Locator Tool does not return the contents of an Index Block, it can be used to traverse down through the base folder and children, though.
Looking over your description, I have a couple of possible ideas:
On a side note, we are currently working on adding search functionality to the Locator Tool and I think that would work wonderfully in this case. Unfortunately, I do not have an ETA on when that will be implemented in a release.
Please let me know if you have any questions.
Thanks!
2 Posted by Justin "JE... on 27 Feb, 2014 04:14 PM
Our asset factory for profile photos does some image resizing, but only forces a specific width.
So, having the content editors pick both resized versions of the image was determined to be a potential problem, and so they wanted a more automatic version.
So, the pages and images have an identical metadata field where they input the users email address, and we compare these to match the images with the page, then render the appropriate sized ones in different places.
So, I know all the images are in _uploads/images/profile/ but the images aren't named consistently enough to programmatically figure out which one to use.
Example images:
Would it be possible to use the locator tool to build an array of all the images in that specific folder? Basically building the index block on the fly, or would that be extremely slow with sometimes 90+ images?
3 Posted by Ryan Griffith on 27 Feb, 2014 04:28 PM
Thank you for clarifying, Justin. I can definitely see how my wouldn't be feasible.
You certainly can. Assuming the path for the folder will always be the same, you can loop over the children within the folder (ie the Image assets) and match up the dynamic metadata field with the one from the calling page and maybe record the images that do match. It's not cached like an Index Block, but might still be fairly quick.
Please let me know if you have any questions.
Thanks!
4 Posted by Justin "JE... on 27 Feb, 2014 05:40 PM
Out of 90 images, this produces the 1 I need for a single page without any real lag time.
I'll probably do a modified version where I store the username and link in an array for the department listing, so I don't use the locator tool 90+ times for each person in the department, as I think searching through an array will be faster than the locator tool is
5 Posted by Ryan Griffith on 27 Feb, 2014 06:44 PM
Yep, you are definitely on the right track.
I would suggest using a Map so you can create a lookup table of name and link. Something like the following:
Please let me know if you have any questions.
Thanks!
6 Posted by Justin "JE... on 28 Feb, 2014 03:51 PM
For our department listings and main campus directory, we build a PHP include file with the pieces of the profile used in those places. To do this, we aggregate an index block from each site into a single page.
So, the code to get our images now looks like the following.
The $subItems[0] is the first page in the index block. We use that to get the site name so we can get all the images for the profiles from that site.
I then store all 3 images in the $profilePhotos map with an additional tag for the size.
Then, to retrieve the images at the correct place in the process, we use the following. The passthrough commands help prevent extra white space and prevent the system from changing the < and > signs.
7 Posted by Ryan Griffith on 28 Feb, 2014 04:31 PM
That looks good, Justin. I am glad to hear the Map direction is working out.
Hopefully if the search functionality I mentioned is implemented for the Locator Tool you will be able to further simplify all of this.
Justin "JET" Turner closed this discussion on 28 Feb, 2014 06:58 PM.