Can anyone tell me if its possible to retrofit inheritance into a Sitecore template?
I have a task to add a new page field into multiple existing templates and I think this should be in a base template.
I've also noticed that the existing templates have fields that should be moved to a base template and then inherited from. Is this possible and if so will there be any side effects with existing code / data?
Yes, it's absolutely ok to add extra base templates to existing Sitecore templates.
E.g. if you already have multiple "page" templates and you need to add extra token for some tracking, you can create new template (let's say "ICustomTracking") and then add it to base templates of your page templates.
To answer your second question: you can "extract" base templates from the existing templates. If you don't want to loose any data, the order of your actions is:
Create new base template
Set this template as a base template for all templates you want it to inherit from.
Move field item from the inheriting template to the base template.
Make sure you move the field item. If you remove the field, and add a new one later, most probably all the data will be lost.
Also it's not recommended to build too complex inheritance structures. It won't be easy to maintain that in the future.
Related
I am having a sitecore template with 5 layers of inheritance. At the top of the inheritance tree, there is a shared field and I want to override it to an unshare field. Meanwhile the only way I can think of is cloning the whole inheritance tree templates which is not an efficient way since I just want to unshare one field and keep the rest 100% the same.
You can't. Fields are unique. Even if you create a new field with the same name on any tier of your template tree, it will be a field on it's own, with its own unique Field ID.
Besides, templates aren't classes. There is no real concept of overriding and inheritance, although the system may make it seem like it at times.
I am creating a webpage that contains several area that always look the same. Just wonder does Django support "global" template?
If it does, is there any reference that I can follow. (I try to google "Django global template" but not such similar things comes up).
Thanks!
Django's template inheritance exactly solves this problem. You can create one base template and change just a block that needs to change in the derived sub-pages.
I'm encountering a dilemma of sorts while making my Django application, but I think the problem I'm encountering may apply to the MVC pattern generally. I'm making a Question model which can be used to construct quizzes or questionnaires. The Question base class would be a simple free response question. I'd like to support different types of questions such as multiple choice questions or sliding scale questions, and these would be subclasses of the Question base class with extra fields added such as an array of possible choices. I'd like to be able to extend my question models to support more types of questions in the future, and for that I can rely on polymorphism and pass objects of the Question type between the model layer and the view layer for all subclasses of Question.
The problem I'm encountering is that the view has to know the type of question it has received in order to render it. If it gets a multiple choice question it needs to draw the radio choice widgets, etc. So now if I extend my models with more types of questions I have to add it to both the model and the view layers. This seems to defeat the point of polymorphism since the views receiving the Question objects would always have to know the subclass type of the questions received. I can get around this problem by delegating the responsibility of rendering the question back to the model. If the Question model has a virtual function called render_question() that its subclasses override then the view layer can call that function to get the right HTML to output without worrying about the type of question. But now I have the problem of having the HTML rendering code bound up with the model.
Could there be a third solution that does not have either of the downsides of the solutions I've thought of? Or is this truly a dilemma about which one has to make a difficult decision?
The separation between model/view is intended to decouple presentation from data. Your initial description of a polymorphic model hierarchy for Question is indeed a valid approach.
What you really want to do here is consider using Django's model inheritance to handle data hierarchies i.e. have:
BaseQuestion <- FreeQuestion,
MultipleChoiceQuestion,
SlidingScaleQuestion etc.
Then you can build a BaseQuestionView that know how to display a BaseQuestion (for instance render the Question string, style it and what not) and using the same principle construct:
BaseQuestionView <- FreeQuestionView,
MultipleChoiceQuestionView,
SlidingScaleQuestionView
You can make the BaseQuestionView abstract as to pull all BaseQuestion model instances from the DB and invoke abstract render_question method that is implemented in each of FreeQuestionView, MultipleChoiceQuestionView, SlidingScaleQuestionView subclasses. Thus FreeQuestionView knows its working with a FreeQuestion model and only implements how to render widget for the answer (textfield). MultipleChoiceQuestionView would only implement how to render radio boxes etc.
In other words it is almost exactly what you presented in your first case, except the rendering implementation lies in the View classes not Model classes.
Same principle can be applied when you want to render the same class of objects in different ways.
With model inheritance you can access any subclass of the base instance with dot notation i.e.: question.freequestion. This will return to you FreeQuestion instance associated with base instance or raise Question.DoesNotExist if that's not its class.
Using class-based views you can add Mixins that can render your question differently depending on the weather this is a FreeQuestion, MultipleChoiceQuestion, using python's MRO pattern, or you can subclass them.
As far as I know there is no automatic way for Django to make the correlation between inherited models and inherited views, you have to make the mapping yourself.
Perhaps the easiest approach is to explicit request all instances matching your initial Question QuerySet related to FreeQuestions, MultipleChoiceQuestions, etc. individually and cast them in the list before feeding it to your main renderer which will then go through a map[question.__class__] to find the renderer method from the mixin. Alternatively you can just keep the question type in the base class as to avoid having to deal with class mappings and let the DB help you in this regard.
However, normally you don't want your model behavior to dynamically change for the same class (which is what you are effectively doing with BaseQuestion). This is especially true when designing with REST in mind, as you want explicit URLs to map to explicit concrete not abstract types.
In classic inheritance, Derived inherits from Base. With mixins, the (technical) base class is usually called the Mixin. What is the proper term for the (technical) class that inherits from the Mixin?
I want to know this so I can name my template parameters accordingly.
The use of a mixin class is an implementation detail that doesn't impact the result as directly as a base/derived relationship in a typical inheritance tree, so I'm not sure it deserves its own name. The one time I used it most successfully there was already an existing base class that was required (MFC's CDialog), so multiple inheritance was used and my mixin wasn't the first one on the list.
If you really have to pick a name, Derived is probably as good as any.
Probably there is no accepted name for that.
Try:
Final
Concrete
Complete
I am using the Poco generator with EF4 and I am wondering if it is possible to edit the T4 template to force all of my entity classes to implement a custom interface. Since the pocos get blown away and recreated each time the custom tool is run, I would have to add this upon each update - I would sure like to avoid that.
I realize I could create partial classes for each poco and implement the interface there, but I was hoping to avoid all that boilerplate code.
Any suggestions would be welcome.
I think I am getting closer to a solution. I am editing the tt template by adding the implemenatation to the signature that is generated.
<#=Accessibility.ForType(entity)#> <#=code.SpaceAfter(code.AbstractOption(entity))#>partial class <#=code.Escape(entity)#> : IEntity<#=code.StringBefore(" , ", code.Escape(entity.BaseType))#>
But I have hit a bit of a snag. Some of my entities have base classes (table inheritance) that I designated in the edmx design. I have need to force all the entities to implement an interface called IEntity. The IEntity contract has no methods so there really is nothing to implement. I will need to rely on all of the entities having a common base. This is due to a completely separate implementation of a custom validation framework. I am getting the proper signatures for most of the entities, however, the entities that already have a base class are throwing a wobbly because you cant implement an interface before you inherit a base class. :IEntity, BaseClass is not allowed. I need to swap those but am not sure how I would pull that off in the template.
On perusing the code in the CodeGenerationTools class that the T4 template uses (found in the include file EF.Utility.CS.ttinclude), I came across this function StringAfter(string value, string append). Therefore, the answer is quite simple, since you state all your entities have to implement IEntity, the following should do the trick:
<#=Accessibility.ForType(entity)#> <#=code.SpaceAfter(code.AbstractOption(entity))#>partial class <#=code.Escape(entity)#> : <#=code.StringAfter(code.Escape(entity.BaseType), "," )#> IEntity
In fact, I know it does because I've tested it :-)
After the T4 template is added to your application, it becomes part of your app and as any other part of the app, you can do whatever you want with it. If for some reason, you don't want to modify the VS added template, make a copy of it and update this to include only the interface implementation. The second way would produce another set of partial files with the custom interface being implemented.
Dont know if this is near what you need but....
I´ve created a Nuget Package that scaffold tiers from T4-templates.
There are default templates for all interfaces (Repository Pattern and UnitOfWork), but you can edit these templates yourself and re-scaffold your system.
To keep it short.. You just install the package (Install-Package CodePlanner) and then define your domainmodel.. And then run "Scaffold CodePlanner.ScaffoldAll"
Its open source (codeplanner.codeplex.com)
Demo: http://average-uffe.blogspot.com/2011/11/codeplanner-011-released-on-nuget-and.html
Edit: The codeplanner package is built for MVC3!
Regards
Uffe