Help shape the future of CMS PaaS release notes! Take this quick survey and share your feedback.
AI OnAI Off
Help shape the future of CMS PaaS release notes! Take this quick survey and share your feedback.
I don't like the IPageViewModel since then you cannot re-use your layout for pages without Episerver content. So I would rather recommend having a LayoutModel without any dependencies to Episerver content. Similar to:
// Use this model in you layout
public class LayoutModel
{
// Properties that your layout requires
}
// Use this model in your page views
public class PageModel<TPage> : LayoutModel
where TPage : PageData
{
public TContent CurrentPage { get; set; }
}
`IPageViewModel` is quite constraining you. Why would you need to implement / inherit some interfaces in order to get layout. Injected layout is decoupled.
With my team we are starting a new project and we are discussing architecture regarding the components like header or footer navigation. I noticed that the Alloy template uses IPageViewModel<T> interface which has a property Layout of type LayoutModel. It is solving a real problem and I think it could be a good fit for our solution.
Because this approach requests to implement a ViewModel for every model that we want to return, I started to look at other potential trade-offs with this approach and I found this article: https://marisks.net/2015/05/18/episerver-strongly-typed-layout-model-without-ipageview/.
And now I am considering a custom WebViewPage to keep a "clean" model but I feel like I might be missing some trade-offs with approach. What are your thoughts on 'Layout' components ? Do you put them inside your model or outside ?