In a recent post on EPiServer World Magnus Stråle described EPiServer’s official view on Page Type Builder. Magnus begins by giving us a history lesson and explaining the reasons behind the classic EPiServer model, aka page types defined in a GUI and property access in a dictionary style. He then answers a question that I get quite a lot: will EPiServer incorporate PTB in their product? And his answer is no.
The motivation is according to Magnus’ post that PTB “is not the ultimate solution but a way to add features that are complementary to the original design decisions”. I’m not sure that I fully agree with the motivation but I do think the decision is good. EPiServer shouldn’t incorporate a plug-in that attempts to solve a problem with the underlying model for two reasons.
First of all that would most likely put blinders on the development team at EPiServer who in my opinion should instead focus on, with great aforethought, how the core model should work in the future.
Another reason is that PTB was born out of a need. Being a commercial product, if EPiServer where to incorporate PTB I’m pretty sure that they would rewrite the whole thing themselves to be on the safe side legally. We would then get a solution that wasn’t really created to solve real problem but instead to solve the problem that the core product didn’t have what an open source product has (and so, Entity Framework was born *duck* ;-)). While I’m sure the developers at EPiServer would do a great job, just rewriting something for commercial reasons would risk adding commercially triggered, but seldom used, bloat.
So you’re happy then?
Well, of course not! ;-) As I said I do think that it’s the correct decision to not include PTB in the CMS but instead focus on how to create a new type of model for pages. But, keep in mind that EPiServer has great influence not only over the framework but also over how it’s used. The templates that ship with the product and the courses that they arrange has a huge impact on how sites are built on top of the CMS. If EPiServer would incorporate PTB in the product they would push it and thereby push a more productive and object oriented way of building sites with the framework. It would also mean that EPiServer could take advantage of having strongly typed page types themselves in both future MVC support and in their own supplementary products.
So you’re actually happy but reserve the right to bitch?
Now you’ve got it! There has to be some benefit to working with open source projects, right? :)
Seriously though, I don’t have a good solution to the problems that I described above, but one suggestion would be to use PTB in the future MVC templates. That is, not in the core product but in the templates. That would send a signal that EPiServer thinks you should use PTB and make it easier for teachers to use PTB in tutorials during courses as it’s endorsed by EPi (I know a few already do).
What do you think?
- A common problem with Page Type Builder and UniqueValuePerLanguage set to false
- Ideas for a new major version of Page Type Builder
- EPiMVC – A framework for using EPiServer CMS with ASP.NET MVC
- Ideas for new features in Page Type Builder 2.0
- Working with Dynamic Properties and Page Type Builder
- How to create a custom EPiServer property
- Getting started with EPiServer CMS development
- EPiServer and MVC – What is the view model?