This issue has plagued us for a while now and I really hope somebody can help.
I have some .NET product related search controls hooked up to macros within Umbraco. The problem is that if we have a search control sitting on 10 or more templates and we want to change a label on this control (a property is exposed to do so) we have 3 inefficient ways of doing so.
1) Store all the values in a RESX file (don't want to be constantly harassed with RESX file change requests)
2) Enter the values directly into each search macro declaration on each template, this would mean copy and pasting the macro across all the templates its declared on (having content edited at template level, especially concerning the macros can lead to exceptions being thrown when speech marks are left off by mistake)
3) Hook all the macro properties up to the forms (doctypes) and edit each node which uses the search macro (this is safer but will also be not very efficient as the user has to remember which template the macro is used on and which nodes use that template)
I'm aware of the Umbraco API but have not yet dabbled with it. Is this the only other solution or could you guys recommend any others?
I appreciate all your help and advice on this problem.
For system wide configuration that you want the user to have control over I tend to create the properties on the homepage doc type, and then just do a recursive call for it.
Another option might be to tie it into a dictionary entry?
Maybe this will help if you decide to go the dictionary route. Its to do with multilingual sites, but tells you how to create dictionary entries and how to retreive them in XSLT:
Yo matt, thanks for your reply, i dont understand this...
"I tend to create the properties on the homepage doc type, and then just
do a recursive call for it."
I have a document type called 'DynamicPages' This contains child doctypes for all dynamic pages on the site. I have my properties created on the DynamicPages doctype for all my search macro properties.
To use them on each template I have to put on each template...
This will get the value from the current node which uses the template. I
want it to get it from a centralised node so I can update them all in one publish. Having all the property values on the FlightSearch doctype and being able to update them in the single node that uses this doctype would be great!
Can you explain further your first suggestion? Thanks.
What I mean by "I tend to create the properties on the homepage doc type, and then just do a recursive call for it." is that I have a template that is used by the root page of the site (ie all other pages on the site are children of this page), I then create the properties I want on this doc type, usualy in a "Settings" tab or simliarly named. Then, when you put you macro on the page, you can do this instead:
Notice the $ instead of #. What this does is recursivley looks down the current nodes ancestors untill it finds a property with that name (in the case I'm suggesting here, the homepage).
It sounds like you have created a master doc type for 'DynamicPages' with child doc types for the pages. Doing it this way though requires you to set it on every instance of that doc type (ie a document).
As a sort of diagram, maybe this will help make it a bit clearer
Home <- doctype = homePage (Properties are defined here in a "Settings Tab") - Some Page 1 <- docType = textPage - Some Page 2 <- docType = dynamicPage (Macro on page looks for property recursivley untill it finds a value) - - Some Sub Page 1 <- docType = dynamicPage (Macro on page looks for property recursivley untill it finds a value)
Hopefully that explains what I meant a little clearer, let me know if not and I'll try again =)
PS The properties don't have to be defined on the homepage, just at a level that contains all dynamicPage instances.
Thanks for the help dude, I will give it a pop soon, I'm just trying to resolve an issue with creating content at the moment :'-( They all seem to hit you all at once!
Matt, I can't thank you enough for your help. This is exactly what we need and has been a big downfall for us not knowing this since the start of our Umbraco project. You have made my day.
Just one thing though :-) When the recursive call can not find a value, it passes the actual call as a paramater value to the control.
For instance, one of my labels for the control is setup with its own property. If I do this...
HeaderLabel="[$headerLabelText]"
If it can't find a value in the recursive call, the label will display it's text as "[$headerLabelText]" as it's default value is being overwritten as Umbraco is passing in the actual recursive call as it's string value. This seems crazy, surely if there is no value found, it should pass an empty string?
You can daisy change your properties together seperated by a comma, so if you had something like this
HeaderLabel="[$headerLabelText],default value"
If it doesn't find a value in [$headerLabelText] it will use the static string "default value". (Or you could look in another field using square brackets again)
Hmm, sounds familiar actualy, but think thats a bug really. As a work around you could do an if statement to see if the valus is surrounded by square brackets?
I'm assuming you mean in the code-behind for the control, if this is the only way around it then I will just have to make sure there is always a value in the field as I don't want to be putting Umbraco specific logic inside of my controls as they are used in other environments outside of Umbraco. If I have understood wrongly, please correct me, or if you have any other ideas please do share them. Cheers.
p.s - do I have to report this bug to the Umbraco devs?
Centralising .NET control property values
Hello,
This issue has plagued us for a while now and I really hope somebody can help.
I have some .NET product related search controls hooked up to macros within Umbraco. The problem is that if we have a search control sitting on 10 or more templates and we want to change a label on this control (a property is exposed to do so) we have 3 inefficient ways of doing so.
1) Store all the values in a RESX file (don't want to be constantly harassed with RESX file change requests)
2) Enter the values directly into each search macro declaration on each template, this would mean copy and pasting the macro across all the templates its declared on (having content edited at template level, especially concerning the macros can lead to exceptions being thrown when speech marks are left off by mistake)
3) Hook all the macro properties up to the forms (doctypes) and edit each node which uses the search macro (this is safer but will also be not very efficient as the user has to remember which template the macro is used on and which nodes use that template)
I'm aware of the Umbraco API but have not yet dabbled with it. Is this the only other solution or could you guys recommend any others?
I appreciate all your help and advice on this problem.
Thanks for your time,
Jonathan
For system wide configuration that you want the user to have control over I tend to create the properties on the homepage doc type, and then just do a recursive call for it.
Another option might be to tie it into a dictionary entry?
Many thanks
Matt
Maybe this will help if you decide to go the dictionary route. Its to do with multilingual sites, but tells you how to create dictionary entries and how to retreive them in XSLT:
http://umbraco.org/documentation/books/multilingual-11-sites/5)-use-the-dictionary-with-an-xslt-extension
Matt
Yo matt, thanks for your reply, i dont understand this...
"I tend to create the properties on the homepage doc type, and then just do a recursive call for it."
I have a document type called 'DynamicPages' This contains child doctypes for all dynamic pages on the site. I have my properties created on the DynamicPages doctype for all my search macro properties.
To use them on each template I have to put on each template...
<umbraco:Macro labelProductHeading="[#flightProductHeading]" Alias="userControlFlightSearch" runat="server"></umbraco:Macro>
This will get the value from the current node which uses the template. I want it to get it from a centralised node so I can update them all in one publish. Having all the property values on the FlightSearch doctype and being able to update them in the single node that uses this doctype would be great!
Can you explain further your first suggestion? Thanks.
Hi Jonathan,
What I mean by "I tend to create the properties on the homepage doc type, and then just do a recursive call for it." is that I have a template that is used by the root page of the site (ie all other pages on the site are children of this page), I then create the properties I want on this doc type, usualy in a "Settings" tab or simliarly named. Then, when you put you macro on the page, you can do this instead:
Notice the $ instead of #. What this does is recursivley looks down the current nodes ancestors untill it finds a property with that name (in the case I'm suggesting here, the homepage).
It sounds like you have created a master doc type for 'DynamicPages' with child doc types for the pages. Doing it this way though requires you to set it on every instance of that doc type (ie a document).
As a sort of diagram, maybe this will help make it a bit clearer
Home <- doctype = homePage (Properties are defined here in a "Settings Tab")
- Some Page 1 <- docType = textPage
- Some Page 2 <- docType = dynamicPage (Macro on page looks for property recursivley untill it finds a value)
- - Some Sub Page 1 <- docType = dynamicPage (Macro on page looks for property recursivley untill it finds a value)
Hopefully that explains what I meant a little clearer, let me know if not and I'll try again =)
PS The properties don't have to be defined on the homepage, just at a level that contains all dynamicPage instances.
Matt
Thanks for the help dude, I will give it a pop soon, I'm just trying to resolve an issue with creating content at the moment :'-( They all seem to hit you all at once!
Matt, I can't thank you enough for your help. This is exactly what we need and has been a big downfall for us not knowing this since the start of our Umbraco project. You have made my day.
Cheers.
Just one thing though :-) When the recursive call can not find a value, it passes the actual call as a paramater value to the control.
For instance, one of my labels for the control is setup with its own property. If I do this...
HeaderLabel="[$headerLabelText]"
If it can't find a value in the recursive call, the label will display it's text as "[$headerLabelText]" as it's default value is being overwritten as Umbraco is passing in the actual recursive call as it's string value. This seems crazy, surely if there is no value found, it should pass an empty string?
Hey,
You can daisy change your properties together seperated by a comma, so if you had something like this
HeaderLabel="[$headerLabelText],default value"
If it doesn't find a value in [$headerLabelText] it will use the static string "default value". (Or you could look in another field using square brackets again)
Matt
Awesome, thanks mate!
No problem, glad I could help
Matt
Hmmm, problems....
It works on current node call
DepartureLabel="[#flightDepartureLabel],testing"
but not on recursive call
DepartureLabel="[$flightDepartureLabel],testing"
Does anyone else experience this problem?
Hmm, sounds familiar actualy, but think thats a bug really. As a work around you could do an if statement to see if the valus is surrounded by square brackets?
Matt
I'm assuming you mean in the code-behind for the control, if this is the only way around it then I will just have to make sure there is always a value in the field as I don't want to be putting Umbraco specific logic inside of my controls as they are used in other environments outside of Umbraco. If I have understood wrongly, please correct me, or if you have any other ideas please do share them. Cheers.
p.s - do I have to report this bug to the Umbraco devs?
Hey Jonathan,
Cool, if you can always have a value, then yea, that's probably the best plan.
Re raising an issue, it looks like it has already been raised, though you may want to vote for it to raise it's priority
http://umbraco.codeplex.com/workitem/26959
Matt
is working on a reply...