I'm a passionate web developer and systems architect. I work as an independent consultant specializing in EPiServer and search.
About web development with ASP.NET and EPiServer, fatherhood and other adventures in my digital jungle
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.
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.
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?
PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.
This blog is built with EPiServer Community, EPiServer CMS, ASP.NET MVC and a bunch of other great products. The source code is available for download at the projects page, where you also can read more about this site and my other projects.
read more
Comments
Tom Stenius 1 years ago
My take on it all, is that I think it would be great to use PTB in several of the template packages to raise the awareness and also to make it easier for developers new to the EPiServer platform to get started - and get started on the correct path!
Magnus Stråle 1 years ago
I'm not sure that there really is a difference of opinion between me and Joel. Quote from article "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". This is my point exactly, although I probably did not emphasize this enough in my original blog post ("EPiServer CMS will provide a way to support strongly typed models.").
Joel Abrahamsson 1 years ago
Magnus, I don't think so either.
What I wanted to point out though is that while you plan for the future it would be a good idea to push people towards PTB as that would mean an easier mental transition to a future new model and produce better sites built today.
Ben Morris 1 years ago
I do agree - PTB seems to be analagous to tool-kits such as Prism for WPF\Silverlight: it's a code library that supports the implementation of design patterns that are widely regarded as best practise in the development community. This doesn't necessarily mean it ought to be incorporated into the core product, though in time EPiServer may incorporate elements of it (e.g. strongly-typed models).
Personally, I'd prefer it if EPiServer concentrated on developing the content management functionality of the core API rather than spending too much time on developer candy. This is, after all, what we sell to our clients...
Stefan Forsberg 1 years ago
In my opinion it's better if EPiServer focuses on making the core product as expandable and open as possible. By that I mean for instance the unit testing story or other area where we as users of the api really have to live with what EPiServer deliver too us. A user control to render some property, while usefull, is something that the developer community quite easily could accomplish on their own. Changing a bunch of static types, internals, non-virtual members etc are a different story.
And let's not forget that PTB sprung out of a real-life problem. Those solutions tend to be better than engineers trying to solve a problem they really haven't had themself but they imagine/are being told about.
That said, things I've heard / seen in the pipeline for EPi vNext like separating the structure of the data from the actuall data bodes well for the future.