If you missed the first post about creating A MODx Ditto Directory this post is designed to describe the same type of 3 level directory (I am referring to the MODx document tree with ‘Levels’), but is a simpler and more elegant technique than what I had first described. Rather than using Ditto and external snippets I have condensed this down to a single, nested PHx call containing 3 separate chunks, each containing a separate Ditto call. Each of those Ditto calls is unique to the level that is being navigated. You will need to have at least some familiarity with creating Ditto calls to create this directory. NOTE: If you are using PHx your Ditto calls should be cached on an uncached page.
In order to have my PHx statement expressed in the correct location I create a second, ‘Directory’ template, identical to my primary one. By doing this you can assign your Template Variables (TV) to this template. I then replace the [*content*] area with the following PHx statement:
[*id:is=`3`:then=`{{level1Directory}}`:else=`[*isfolder:is=`1`:then=`{{level2Directory}}`:else=`{{level3Page}}`*]`*]
That’s really all there is to it. The information below is a more detailed explanation of what is occurring at each level of the directory in addition to a more advanced technique that creates a cross-categorization feature.
Document Structure
- Level1 (Directory Overview – Displays Categories) This level uses the top document ID (my example: 3) of your Direcoryty to identify which Ditto call is to be expressed first as you were navigating down the document tree.
In this example we are using Ditto to call down to Level2 to return variables onto this Level1 page. This will create a ‘Category Views’ page.
[!Ditto? &startID=`[*id*]` &depth=`1` &tpl=`directoryTopTPL` &sortDir=`asc`!]
- Level2 (Single Category Overview – Displays Category Members) Level2 folders are the ‘Categories’ in this technique. This level uses the isfolder:is=`1` portion of the PHx statement. Which expresses a second Ditto call if the document is a folder, but does not posses a Level1 document ID.
In this example we are using Ditto to call down to Level3 to partially or fully return variables within the children of a particular category. On Level1 I clicked a category, now I see the members of that category. From here I click to see a Level3 page with full member data.
[!Ditto? &startID=`[*id*]` &depth=`2` &tpl=`directoryFolderTPL`!]
- Level3 (Member Overview – Displays Individual Page Data) Level3 pages are the final level of the Directory, the individual pages which contain all of the specific member data. This level uses the :else= portion of the PHx statement and is expressed if neither of the first two criteria are met.
In this example we are using the &startID=`[*id*]` statement within a Ditto call to bring in the variables assigned to this particular page. We are basically saying, ‘return the variables for the page you are viewing’.
[!Ditto? &documents=`[*id*]` &depth=`2` &tpl=`directoryPageTPL` &summarize=`10` &paginate=`1` &paginateAlwaysShowLinks=`1`!]
The End User
As with my previous post I also use the ManagerManager snippet to hide any unused fields from the end user or to keep them from changing fields like the ‘Uses Template’. That way all that is seen are the fields that are needed (which are usually the pagetitle and then the associated TVs). By using this approach, with a little instruction, the end user is able to build new Level2 and Level3 pages on the fly. Since we are using a single template for all these pages the correct template (and TVs) are inherited from the parent as new pages are being created. From the end user’s perspective it is pretty effortless.
Cross Categorization – Advanced
One of the limitations of this approach that I have been struggling with is that this technique, until now, lacks the ability to cross-categorize. Well, thanks to Bill Wheeler’s (@swscripts) coding, we have developed a method for tackling this issue. The first step is to create a Multi-select or Checkbox TV that will return the list of Level2 containers and assign it to your template. This becomes a cross-categorization list for your Level3 directory documents. In this example I have used the Quill snippet to create this TV list, but a Ditto call in the TV will work as well.
This also requires a slight modification to the Level2 Ditto call (below). What we are wanting is to return all the documents assigned to a category, rather than just the contents of a single Level2 directory. You must now go up a level higher to return all to the Directory Level3 documents rather than just the contents of the active Level2. It also requires the exclusion of the Level2 folders and the addition of a filter to return the documents within a given category.
[!Ditto? &startID=`[[UltimateParent? &topLevel=`0`]]` &depth=`2` &tpl=`directoryFolderTPL` &hideFolders=`1` &filter=`category1,[*id*],7` !]
The second step is where I needed to pull in a little coding help to create a plugin. At this stage of the game the cross categorization works, but once a member was placed in a category the end user would still have to go in and select the same category again (because we have somewhat divorced the categorization from the structure of the document tree) from the TV created by the Quill snippet. I really didn’t think this redundancy of process was acceptable. What I needed was for the TV to inherit the document ID of the parent, thus forcing it to be placed in the category in which it actually resides.
The end result: Personnel_Checker. This plugin will return the parent document ID and then place it into the appropriate TV with the timing of ‘OnBeforeDocFormSave’.
Hey Greg,
I know this may seem fundamental, but your post highlighted something that it confusing for me at times: when to cache & when not to cache. It seems like a no brainer, but there are times when I'm making Ditto, PHx, or MaxiGallery calls and I'm just not certain when to cache or not.
Do you recommend any good resources? Or maybe doing a post about it?
Thanks!
March 4th, 2010 at 10:47 pm
That is a good question and there's not a lot of resources our there on the topic, there is a pretty basic post here: http://bobsguides.com/modx-cache.html You're right, that would make a good post.
March 4th, 2010 at 10:53 pm
Please correct me if I'm wrong, but wouldn't it be an even simpler solution to just collect all level 3 documents in one seperate (non navigation visible) folder and just assign all categories via the TV?
That way you would not have to mix one “physical” category for each level 3 element (= its parent folder) with a bunch of “virtual” categories (assigned via the TV). The level 2 elements would then only be used to show the different lists of level 3 elements.
March 4th, 2010 at 11:36 pm
How would you then navigate this?
March 4th, 2010 at 11:44 pm
Cool…I'll check it out! Thanks.
March 5th, 2010 at 12:10 am
Let me just finish the templating for my personal blog which is going to be a MODx site. I want to use a solution like the one we are discussing here for my category system. I'll show you the templates etc. as soon as it works (well, if it works the way I'm thinking of
)
March 5th, 2010 at 7:48 am
Sounds great, I would love to see another angle to this. I personally like my approach without the cross-categorization portion of it. I realize that the addition of this feature is important but might makes things a little clunky, that's why I tried to separate out the two techniques. I can't wait to hear back from you. Thanks!
March 5th, 2010 at 12:37 pm
Can you point to a site where you've implemented this?
March 9th, 2010 at 10:09 am
Try it here: http://lyon.pleth.net/personnel-directory.htm
March 9th, 2010 at 11:55 am
Finally I could finish the blog. It's online: http://www.michael-van-laar.de/blog/ I want to write a little article series (with screenshots of the backend, structure etc.) about setting up a blog with MODx. But since this will be in German, here's a brief abstract.
1. All blog articles (corresponsing to the people in your personnel directory example) are documents in the container http://www.michael-van-laar.de/blog/artikel/ – regardless of any assigned categories.
2. All blog categories (“Themen” in German; corresponding to the departments in your example) are documents in the container http://www.michael-van-laar.de/blog/themen/. These documents have two functions: On one hand they serve as assignable categories for blog articles. On the other hand they are used to display all articles of the respective category. I use this type of category system rather than just tags because by having a distinct document for each category I am able to enter additional information for each category, e. g. a short description (wich automatically appears on the category page itself as well as on the category overview page) or a special search engine optimized content for the title tag of the category page.
3. One or more categories can be assigned to blog articles via a template variable. This TV has “@SELECT pagetitle, id FROM [+PREFIX+]site_content WHERE parent='10' ORDER BY menuindex ASC” as input value and check boxes as input type.
Advantages from my point of view:
1. I don't have a mixture of “physical” and “virtual” categories, since they are all “virtual”. (Which means that the category documents are no containers with articles in them.)
2. I don't even have to assign any category at all to an article, if I don't want to.
3. Even if I change the assigned categories for an article, the article's URL will never change (permalink character of blog article URLs). This is very important since I use the path option for user friendly URL creation. If I would place the single articles under one of the category pages instead, the URL of an article would change inevitably, as soon as I would have to move it to another caterogy.
So this structure provides maximum flexibility for me, combined with nice meta information rich blog categories.
April 5th, 2010 at 10:08 am
Thanks for sharing this!
April 5th, 2010 at 12:43 pm
Thank you this nice post
April 18th, 2010 at 8:53 am
Hi Greg, I am looking at your and Michael's solution. I can see the beauty of putting all articles/documents in one place, but in your solution you can assign manager users I believe and I do not see how that is done in Michael's. Unless I am missing something. I like the idea of putting all articles in a single container and controlling by TV, but in my current project how do you allow different– manufacturers in my case–users (managers) only access to their own articles to add and edit if I put all documents in one place. It seems much more complicated.
April 21st, 2010 at 3:32 pm
I haven't actually dealt with trying to limit access for managers in this technique. It sounds like you may be asking me how do you accomplish this using Michael's technique in which all the documents “live” in a single container. In that instance I would probably refer you over to Michael.
In my technique I would assume you could tackle it by using a master group that all managers belong to and thus have access to the parent container of your directory. That way they can all “see” the parent (you could then use ManagerManager to keep them out of this document). Following that you could then allow them to access only the “category” directories at the next level that you wish.
Hope that helps!
April 21st, 2010 at 3:48 pm
Thanks Greg. I have a situation where I do not want different managers to have access to common documents. That is why I saw in your technique the security of separate containers. But at the same time with many managers I would have a separate article folder for each which seems awfully inefficient.
April 21st, 2010 at 7:16 pm
Well , the view of the passage is totally correct ,your details is really reasonable and spring-bags.com you guy give us valuable informative post, I totally agree the standpoint of upstairs. I often surfing on this forum when I m free and I find there are so much good information we can learn in this forum!
June 8th, 2010 at 3:46 am
Photo Galleries with Ditto & ManagerManager | Greg Smart says:
[...] (see below). For the purpose of this example you can ignore the category checkboxes, this previous post explains their use in a cross-categorization technique. To create your galleries just create a new [...]
July 9th, 2010 at 1:14 pm
“Well , the coach outlet view of coach handbags the passage is totally correct ,your details is really reasonable and you guy give us valuable informative post, I totally agree the standpoint of upstairs. I often surfing on this forum when I m free and I find there are so much good information we can learn in this forum!
ugg classic tall stripe cable knit boots
July 14th, 2010 at 7:51 am