Property Aliases Naming Best Practices for Website with Multiple Pages
Hi,
Does anyone know what the best practice is for naming property aliases in the document types you add to your project. Say you have a website that has 100 pages (and 100 document types), would you name the property aliases for content on each of those pages with the same name even though the pages relate to different things, or would you use generic property aliases names?
For example, if Document Type 1 has 10 properties in one tab called "Content", and this page relates to Topic A, and if Document Type 2 has 11 properties in one tab called "Content" as well, and this page relates to Topic B, would you name the property aliases the same for the first 10 properties, so as to make things easier for searching?
Are there pros and cons to each approach (naming the properties the same vs naming the properties different)?
I'm not sure I understand the question. A more concrete example might help.
What I typically do is name things as simply as I can. For example, I'll create a property on most doctypes called "Main Content" (that holds the Archetype widgets). And I'll create a property called "Meta Description" (for the SEO meta description).
For product pages that have very specific properties, I might have properties like "Price" and "Weight".
I tend to avoid naming properties that might collide with the name of built-in properties (e.g., "Name", "URL", "Publish Date", "ID", and so on). For a product, I might call the property "Product Name" rather than "Name".
I also have various document type compositions so I don't have to recreate these properties for each document type. Also, I don't create a new document type unless there's a good reason to do so.
I see. I can provide a simple example to clarify my question.
If you have a site that has the following node structure:
-Homepage
-->About
-->FAQ
-->Contact Us
Each of these pages has a different design. Homepage has some content and a footer. About is designed similar to header, but positioning of the content is different. FAQ has a question and answer type design, and Contact Us has a contact form and map. All these pages use a Master.cshtml for design content that is similar on every page.
Each of the aforementioned pages has a document type similar to yours: a Tab for SEO and a tab for Content. However, the property aliases for the Content tab differ for each page: i.e. the Homepage may have property aliases: homePageMainTitle, homePageSubTitle, homePageMainContent, homePageSubContent, etc. The about page may have aboutMainTitle, aboutSubTitle, aboutMainContent, and aboutSubContent. This repeats for each document type.
I set things up like this so that I would not contain document types that are really large with unused properties for specific template pages (i.e. the FAQ Page would not utilize the homePageSubTitle or homePageSubContent, because it requires properties like: generalQuestion1, generalAnswer1, generalQuestion2, generalAnswer2, ...etc... miscellaneousQuestion1, miscelleneousAnswer2, ... miscellaneousQuestion10, miscellaneousAnswer10, etc.)
I was worried that if I created a document type that contained all of these unique propertyAliases, then things may be slow, and the document type would be unnecessarily large.
If I'm understanding you correctly, it sounds like there may actually be two questions you are asking:
Should properties be prefixed with the document type name?
Should properties be combined into shared document types that can be used by different pages?
My short answers would be:
No.
No.
Prefixing Doctype to Properties
I wouldn't do this because I see no reason for it. It's almost as if you are trying to namespace the properties. They aren't going to collide with properties on other document types, so I don't see why you are doing this. Unless you are nesting your document type definitions in the same way your content is structured, in which case I would recommend further looking into document type compositions and avoiding nesting of document types altogether.
Combine Doctype Properties
I wouldn't do this because part of the reason you have doctypes is to structure different pages differently. Why have a page with a bunch of unused properties? That could be very confusing for a content editor, and it has seemingly no purpose.
Additional Observations
For an FAQ page, I would recommend something like Archetype or Nested Content. That way, you can create a single property that can contain an unlimited number of questions and answers.
In the widget approach, pretty much every document type has the same properties (depending on your site, that might be the same 5 or so properties). A few pages, such as the homepage and product pages, might be exceptions to this.
Further Clarification
I suppose I don't understand the motivation of the scenario you describe. If you could explain what you are trying to accomplish by prefixing properties and combining properties, I might be able to go into more detail.
The motivation for the scenario was me trying to determine whether I need to fix my property types by deleting the multiple property types in each of my 100 document types, and create generically named property types. I assumed that custom (prefix) property types would be important for indexing when it comes to trying to search with lucene. I was unclear on whether you should create a doc type for each web page in your site.
Luckily, I have not combined properties (I have 100 website pages, and 100 document types: all with different property aliases (none really overlap with names...whether that was a good thing or bad thing, I'm not sure, but I hope it wasn't a bad move)). I'm glad that properties should not be combined in my scenario, that saves me from going back to do extra work.
With respect to the motivation behind the different property names, I had to build a fully customized website with search functionality. In order for the search to function correctly, I needed to add various property types on all the pages, so I assumed they would have to be unique so that there would be no issues when a query is made using lucene (specifically, I am using the ezSearch add-on).
I asked this question because now I have a lot of property types, and this is creating an issue for ezSearch (when a user types in more than one word into the search it gives an error). I thought that this could be due to me creating a document type for each web page in the site, and also, multiple property aliases in each of those document types.
Fair point with respect to the FAQ page. I was unsure as to whether the search would function correctly with a single property type that can contain an unlimited number of questions and answers in the FAQ page.
Essentially, I was unsure whether different document types that have different property types for each web page of the site was a bad move, and whether those property types should have been given generic names.
Does your search require the ability to filter by page type? One way to do that would be to construct the Lucene query to filter by document type alias.
Regarding searching content stored by Nested Content or Archetype (e.g., an FAQ), you can expand the JSON and store them in a munged field.
If the number of different property names are causing issues with ezSearch, perhaps you can rename the properties so they don't have the document type prefixed. You'll want to back up the database before doing that (just in case something goes wrong).
Thanks for your reply. What do you mean exactly by filter by page type?
I'll check the link re munged fields. I've never head of that before.
The error I'm getting with ezsearch is:
maxClauseCount is set to 1024
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Lucene.Net.Search.BooleanQuery+TooManyClauses: maxClauseCount is set to 1024
Source Error:
Line 111: }
Line 112:
Line 113: var criteria2 = criteria.RawQuery(query.ToString());
Line 114:
Line 115: var results = searcher.Search(criteria2)
It happens when the search query is more than one term.
Good point regarding renaming the property names prefix. I may need to rename them to something generic. Is there a way to go back to the old property alias names, if things don't work out, (i.e. undo the renaming)? I'm not sure how to back up the databases for an unpublished site.
The only reason I could think of prefixing each property with the document type was that you were trying to allow the user to perform a search and allow the search to be filtered by page type (e.g., "Home', "About", and so on). Maybe with a drop down or something. Seems like that's not the case.
I'd guess you are getting that error because you have over 512 properties, and when you multiply that by two (one for each term) you get over 1024 search clauses. The solution would be to rename the properties so there aren't so many of them.
Is there a way to go back to the old property alias names, if things don't work out, (i.e. undo the renaming)? I'm not sure how to back up the databases for an unpublished site.
Not sure what you mean. If you are using SQL Server, you'd use SQL Server Management Studio to backup the database. If you are using SQL Server CE (hopefully not), you can copy the SDF file (which is the database).
Thanks Nicholas, that is extremely helpful. I will start renaming properties to remove the prefix.
If I find a property that can be repeated, will this have a negative impact on my search? I.e. if there is a property called aTestProperty and bTestProperty, each in a different document type, and I rename those properties to a generic name: "testProperty" instead, will this effect the search when testProperty contains different content in each of those document types (on different pages in the site)?
I am running the site on my local computer in Visual Studio 2015 Community.
It shouldn't negatively impact the search as far as I know, but I'd probably just give it a test run with a property or two to see what happens. You may have to republish the content after renaming the properties to ensure the caches are all updated (most importantly, the Examine indexes).
I am running the site on my local computer in Visual Studio 2015 Community.
FYI, this should have no impact on the search or the database. All database options are available regardless of how the site is hosted (e.g., IIS, VS). Your web.config should have a connection string that indicates the type of database you have (which should help you figure out how to backup).
Thanks Nicholas! I know it's hosted in IIS express, but I'll have to check it out.
Good point re the test run. There are so many property aliases that it will be very tedious to change them all :s, but a test of a couple should ensure it doesn't get done in vein. I wish there was a faster and easier way to change all the property aliases.
I was playing around with the idea to increase the default maxClauseCount from 1024 to something more, but I am worried that this will slow things down...
Property Aliases Naming Best Practices for Website with Multiple Pages
Hi,
Does anyone know what the best practice is for naming property aliases in the document types you add to your project. Say you have a website that has 100 pages (and 100 document types), would you name the property aliases for content on each of those pages with the same name even though the pages relate to different things, or would you use generic property aliases names?
For example, if Document Type 1 has 10 properties in one tab called "Content", and this page relates to Topic A, and if Document Type 2 has 11 properties in one tab called "Content" as well, and this page relates to Topic B, would you name the property aliases the same for the first 10 properties, so as to make things easier for searching?
Are there pros and cons to each approach (naming the properties the same vs naming the properties different)?
I'm not sure I understand the question. A more concrete example might help.
What I typically do is name things as simply as I can. For example, I'll create a property on most doctypes called "Main Content" (that holds the Archetype widgets). And I'll create a property called "Meta Description" (for the SEO meta description).
For product pages that have very specific properties, I might have properties like "Price" and "Weight".
I tend to avoid naming properties that might collide with the name of built-in properties (e.g., "Name", "URL", "Publish Date", "ID", and so on). For a product, I might call the property "Product Name" rather than "Name".
I also have various document type compositions so I don't have to recreate these properties for each document type. Also, I don't create a new document type unless there's a good reason to do so.
I see. I can provide a simple example to clarify my question.
If you have a site that has the following node structure:
-Homepage
-->About
-->FAQ
-->Contact Us
Each of these pages has a different design. Homepage has some content and a footer. About is designed similar to header, but positioning of the content is different. FAQ has a question and answer type design, and Contact Us has a contact form and map. All these pages use a Master.cshtml for design content that is similar on every page.
Each of the aforementioned pages has a document type similar to yours: a Tab for SEO and a tab for Content. However, the property aliases for the Content tab differ for each page: i.e. the Homepage may have property aliases: homePageMainTitle, homePageSubTitle, homePageMainContent, homePageSubContent, etc. The about page may have aboutMainTitle, aboutSubTitle, aboutMainContent, and aboutSubContent. This repeats for each document type.
I set things up like this so that I would not contain document types that are really large with unused properties for specific template pages (i.e. the FAQ Page would not utilize the homePageSubTitle or homePageSubContent, because it requires properties like: generalQuestion1, generalAnswer1, generalQuestion2, generalAnswer2, ...etc... miscellaneousQuestion1, miscelleneousAnswer2, ... miscellaneousQuestion10, miscellaneousAnswer10, etc.)
I was worried that if I created a document type that contained all of these unique propertyAliases, then things may be slow, and the document type would be unnecessarily large.
Hope this clears up my question?
If I'm understanding you correctly, it sounds like there may actually be two questions you are asking:
My short answers would be:
Prefixing Doctype to Properties
I wouldn't do this because I see no reason for it. It's almost as if you are trying to namespace the properties. They aren't going to collide with properties on other document types, so I don't see why you are doing this. Unless you are nesting your document type definitions in the same way your content is structured, in which case I would recommend further looking into document type compositions and avoiding nesting of document types altogether.
Combine Doctype Properties
I wouldn't do this because part of the reason you have doctypes is to structure different pages differently. Why have a page with a bunch of unused properties? That could be very confusing for a content editor, and it has seemingly no purpose.
Additional Observations
For an FAQ page, I would recommend something like Archetype or Nested Content. That way, you can create a single property that can contain an unlimited number of questions and answers.
Also, you might want to consider a widget approach to building websites: http://skrift.io/articles/archive/building-umbraco-websites-with-archetype-widgets-and-ditto/
In the widget approach, pretty much every document type has the same properties (depending on your site, that might be the same 5 or so properties). A few pages, such as the homepage and product pages, might be exceptions to this.
Further Clarification
I suppose I don't understand the motivation of the scenario you describe. If you could explain what you are trying to accomplish by prefixing properties and combining properties, I might be able to go into more detail.
Thanks for the reply.
The motivation for the scenario was me trying to determine whether I need to fix my property types by deleting the multiple property types in each of my 100 document types, and create generically named property types. I assumed that custom (prefix) property types would be important for indexing when it comes to trying to search with lucene. I was unclear on whether you should create a doc type for each web page in your site.
Luckily, I have not combined properties (I have 100 website pages, and 100 document types: all with different property aliases (none really overlap with names...whether that was a good thing or bad thing, I'm not sure, but I hope it wasn't a bad move)). I'm glad that properties should not be combined in my scenario, that saves me from going back to do extra work.
With respect to the motivation behind the different property names, I had to build a fully customized website with search functionality. In order for the search to function correctly, I needed to add various property types on all the pages, so I assumed they would have to be unique so that there would be no issues when a query is made using lucene (specifically, I am using the ezSearch add-on).
I asked this question because now I have a lot of property types, and this is creating an issue for ezSearch (when a user types in more than one word into the search it gives an error). I thought that this could be due to me creating a document type for each web page in the site, and also, multiple property aliases in each of those document types.
Fair point with respect to the FAQ page. I was unsure as to whether the search would function correctly with a single property type that can contain an unlimited number of questions and answers in the FAQ page.
Essentially, I was unsure whether different document types that have different property types for each web page of the site was a bad move, and whether those property types should have been given generic names.
Does your search require the ability to filter by page type? One way to do that would be to construct the Lucene query to filter by document type alias.
Regarding searching content stored by Nested Content or Archetype (e.g., an FAQ), you can expand the JSON and store them in a munged field.
You can read a bit about that here: https://kevin.giszewski.com/blogs/2016/01/minimum-viable-product-part-7-searching-content/
If the number of different property names are causing issues with ezSearch, perhaps you can rename the properties so they don't have the document type prefixed. You'll want to back up the database before doing that (just in case something goes wrong).
Thanks for your reply. What do you mean exactly by filter by page type?
I'll check the link re munged fields. I've never head of that before.
The error I'm getting with ezsearch is:
maxClauseCount is set to 1024
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Lucene.Net.Search.BooleanQuery+TooManyClauses: maxClauseCount is set to 1024
Source Error:
Line 111: }
Line 112:
Line 113: var criteria2 = criteria.RawQuery(query.ToString());
Line 114:
Line 115: var results = searcher.Search(criteria2)
It happens when the search query is more than one term.
Good point regarding renaming the property names prefix. I may need to rename them to something generic. Is there a way to go back to the old property alias names, if things don't work out, (i.e. undo the renaming)? I'm not sure how to back up the databases for an unpublished site.
The only reason I could think of prefixing each property with the document type was that you were trying to allow the user to perform a search and allow the search to be filtered by page type (e.g., "Home', "About", and so on). Maybe with a drop down or something. Seems like that's not the case.
I'd guess you are getting that error because you have over 512 properties, and when you multiply that by two (one for each term) you get over 1024 search clauses. The solution would be to rename the properties so there aren't so many of them.
Not sure what you mean. If you are using SQL Server, you'd use SQL Server Management Studio to backup the database. If you are using SQL Server CE (hopefully not), you can copy the SDF file (which is the database).
Thanks Nicholas, that is extremely helpful. I will start renaming properties to remove the prefix.
If I find a property that can be repeated, will this have a negative impact on my search? I.e. if there is a property called aTestProperty and bTestProperty, each in a different document type, and I rename those properties to a generic name: "testProperty" instead, will this effect the search when testProperty contains different content in each of those document types (on different pages in the site)?
I am running the site on my local computer in Visual Studio 2015 Community.
It shouldn't negatively impact the search as far as I know, but I'd probably just give it a test run with a property or two to see what happens. You may have to republish the content after renaming the properties to ensure the caches are all updated (most importantly, the Examine indexes).
FYI, this should have no impact on the search or the database. All database options are available regardless of how the site is hosted (e.g., IIS, VS). Your web.config should have a connection string that indicates the type of database you have (which should help you figure out how to backup).
Thanks Nicholas! I know it's hosted in IIS express, but I'll have to check it out.
Good point re the test run. There are so many property aliases that it will be very tedious to change them all :s, but a test of a couple should ensure it doesn't get done in vein. I wish there was a faster and easier way to change all the property aliases.
I was playing around with the idea to increase the default maxClauseCount from 1024 to something more, but I am worried that this will slow things down...
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.