I'm fairly new to Umbraco and am just blown away by the power and customization that it offers. Really an amazing system. However, with that freedom, I realize comes a lot more options to screw up.
I am a developer for a college and have the task of redeveoping the entire college site on a new CMS ( I have chosen Umbraco ). I am currently in the planning stage and have a couple questions on best practices.
1. How does a large content tree impact backoffice performance? What suggestions would you give for a very large site?
2. I've seen mention of 'data nodes'. Apparently, content nodes that do not display pages? I've found very little on this, but would like to know to what they are referring to and how they are used.
3. Being a college we'll have a variety of content that belongs to individual departments as well as the college as a whole. I'm at a loss on how to structure these in the system.
Example: Staff bios, campus events, news articles, etc. Departments will want to display staff bios on their individual deptmant pages, but the college will also need an all encompassing staff page. Obvisouly, we'd like to avoid duplicate data, so what would be the best approach to this?
a. Have a 'staff' folder in the parent of the tree which contains all staff members? The doc type would have an identifier that connects a staff member to a department. The department would then just have to create a page with a doc type that pulls in members from their department. However, there are a few problems with this. 1. All editors would be able to edit the staff members of a department they may not belong too (not ideal). 2. The tree maybe be a little confusing without having the bios under their departments tree node.
b. Departments have the option of creating a Staff page and individual bios under the department node. The problem here is that there wouldn't be an easy way to have an all encompassing staff page. We couldn't just pull from all the departments, because not all departments will have a staff page (leading to a lack of data). Then there'd be duplicate data (and possiblities of inconsistancies between each instance) if we did both options.
The example of staff bios holds true for events, news releases, and other instances.
I can't answer all your questions but for your staff example, why not just use your example "a" and have a "staffDepartment" doc type under "staff", then add "staffMember" under each dept. That way you can still display all staff where you want by traversing tree and looking for docTypes of "staffMember", but can also lock these "staffDepartments" down to only users (staff) of that dept.
So:
STAFF --> DEPARTMENT --> STAFF MEMBER X
When setting up permissions, a person would only have access to a particular STAFF-->DEPARTMENT
There may be a better way to do it, I'm no expert.
Speaking of data nodes, not sure what that means, but we certainly use docTypes with no template (i.e. no page), purely for organising things in the content tree. For example we would have a "settings" docType, which in content tree will have things like "footerLinks" and "homepageCarouselItems" etc under it.
Questions about nodes, trees, & best practices
Greetings,
I'm fairly new to Umbraco and am just blown away by the power and customization that it offers. Really an amazing system. However, with that freedom, I realize comes a lot more options to screw up.
I am a developer for a college and have the task of redeveoping the entire college site on a new CMS ( I have chosen Umbraco ). I am currently in the planning stage and have a couple questions on best practices.
1. How does a large content tree impact backoffice performance? What suggestions would you give for a very large site?
2. I've seen mention of 'data nodes'. Apparently, content nodes that do not display pages? I've found very little on this, but would like to know to what they are referring to and how they are used.
3. Being a college we'll have a variety of content that belongs to individual departments as well as the college as a whole. I'm at a loss on how to structure these in the system.
Example:
Staff bios, campus events, news articles, etc. Departments will want to display staff bios on their individual deptmant pages, but the college will also need an all encompassing staff page. Obvisouly, we'd like to avoid duplicate data, so what would be the best approach to this?
a. Have a 'staff' folder in the parent of the tree which contains all staff members? The doc type would have an identifier that connects a staff member to a department. The department would then just have to create a page with a doc type that pulls in members from their department. However, there are a few problems with this. 1. All editors would be able to edit the staff members of a department they may not belong too (not ideal). 2. The tree maybe be a little confusing without having the bios under their departments tree node.
b. Departments have the option of creating a Staff page and individual bios under the department node. The problem here is that there wouldn't be an easy way to have an all encompassing staff page. We couldn't just pull from all the departments, because not all departments will have a staff page (leading to a lack of data). Then there'd be duplicate data (and possiblities of inconsistancies between each instance) if we did both options.
The example of staff bios holds true for events, news releases, and other instances.
Thanks. I'm excited to get working with Umbraco.
I can't answer all your questions but for your staff example, why not just use your example "a" and have a "staffDepartment" doc type under "staff", then add "staffMember" under each dept. That way you can still display all staff where you want by traversing tree and looking for docTypes of "staffMember", but can also lock these "staffDepartments" down to only users (staff) of that dept.
So:
STAFF --> DEPARTMENT --> STAFF MEMBER X
When setting up permissions, a person would only have access to a particular STAFF-->DEPARTMENT
There may be a better way to do it, I'm no expert.
Speaking of data nodes, not sure what that means, but we certainly use docTypes with no template (i.e. no page), purely for organising things in the content tree. For example we would have a "settings" docType, which in content tree will have things like "footerLinks" and "homepageCarouselItems" etc under it.
is working on a reply...