Though, this method has been incorporated in Contacts module (ContactsList and SingleContact controls), I haven't talked about it yet. You can use this method for administrative or public controls (it comes especially handy with public controls). I'll explain the concept here for the public control (for admin controls the method is same, except that user can't set TemplatePath through page editor).
Take a look at following graphic to see the logic of implementing templates on public side controls in Sitefinity (at least the logic we use :).
We used to do all decision making in CreateChildControls method and that's what you could have seen in some of my older examples. However, if you open ContactsList control from the Contacts module and take a look at the CreateChildControls method, you'll see that all this has been reduced to one single line now:
The question now is, how does the LayoutTemplate property know which template (take a look at the graphic if you have forgot our template dilemma) to load. This is how the LayoutTemplate property looks like:
As you can see from the get accessor, if layoutTemplate is not null (meaning that it has been set declarative or loaded in some other way) we return that template. That was the first question from the graphic. On the other hand, if the layoutTemplate is null, we invoke static generic method of ControlUtils.GetTemplate, to which we pass the type parameter of our default template class (4th-final solution from the graph) and LayoutTemplatePath property. The LayoutTemplatePath property will resolve the questions 2 and 3 from the graphic. This is how it looks like:
In the get accessor, LayoutTemplatePath property checks if user has set the property through property grid in control editor (if yes, object would exist in ViewState), otherwise it tries to get the path from the provider.
Everything else is left to the ControlUtils.GetTemplate method which will return an appropriate template. As an added bonus, ControlUtils.GetTemplate will also cache your template, thus improving the performance of your application.
Once again, you can see this in action in Contacts module provided on this blog in ContactsList or SingleContact controls. Let me know if you have any questions...
P.S. to the readers of Sitefinity Social Network Platform series – I am working on it and the next post should appear tomorrow or at latest day after tomorrow. Thank you for you patience.
Take a look at following graphic to see the logic of implementing templates on public side controls in Sitefinity (at least the logic we use :).
We used to do all decision making in CreateChildControls method and that's what you could have seen in some of my older examples. However, if you open ContactsList control from the Contacts module and take a look at the CreateChildControls method, you'll see that all this has been reduced to one single line now:
| this.LayoutTemplate.InstantiateIn(this.layoutContainer); |
The question now is, how does the LayoutTemplate property know which template (take a look at the graphic if you have forgot our template dilemma) to load. This is how the LayoutTemplate property looks like:
| [Browsable(false)] |
| [DefaultValue((string)null)] |
| [TemplateContainer(typeof(ContactsList), BindingDirection.OneWay)] |
| [PersistenceMode(PersistenceMode.InnerProperty)] |
| public virtual ITemplate LayoutTemplate |
| { |
| get |
| { |
| if (this.layoutTemplate == null) |
| this.layoutTemplate = ControlUtils.GetTemplate<DefaultTemplate>(this.LayoutTemplatePath); |
| return this.layoutTemplate; |
| } |
| set |
| { |
| this.layoutTemplate = value; |
| } |
| } |
| |
As you can see from the get accessor, if layoutTemplate is not null (meaning that it has been set declarative or loaded in some other way) we return that template. That was the first question from the graphic. On the other hand, if the layoutTemplate is null, we invoke static generic method of ControlUtils.GetTemplate, to which we pass the type parameter of our default template class (4th-final solution from the graph) and LayoutTemplatePath property. The LayoutTemplatePath property will resolve the questions 2 and 3 from the graphic. This is how it looks like:
| [Category("Appearance")] |
| public string LayoutTemplatePath |
| { |
| get |
| { |
| object obj = this.ViewState["LayoutTemplatePath"]; |
| if (obj != null) |
| return (string)obj; |
| return ContactsManager.Providers[this.ProviderName].ContactsListTemplate; |
| } |
| set |
| { |
| this.ViewState["LayoutTemplatePath"] = value; |
| } |
| } |
| |
In the get accessor, LayoutTemplatePath property checks if user has set the property through property grid in control editor (if yes, object would exist in ViewState), otherwise it tries to get the path from the provider.
Everything else is left to the ControlUtils.GetTemplate method which will return an appropriate template. As an added bonus, ControlUtils.GetTemplate will also cache your template, thus improving the performance of your application.
Once again, you can see this in action in Contacts module provided on this blog in ContactsList or SingleContact controls. Let me know if you have any questions...
P.S. to the readers of Sitefinity Social Network Platform series – I am working on it and the next post should appear tomorrow or at latest day after tomorrow. Thank you for you patience.