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
Since Paul Smith posted about EPiServer having implemented native support for page types declared as classes in the next version of the CMS I've gotten quite a few questions about it. Almost all of them can be distilled down to two:
The short answer to the first question is that I'm both somewhat relieved and glad, but also scared. The answer to the second question is no.
I'm relieved as EPiServer shipping with a native implementation might mean that I won't have to spend more time and energy on Page Type Builder. While it's been a fun couple of years building and maintaining the project I've often felt I haven't been able to give it the attention that I would have liked to. For instance, Lee Crowe has contributed far more to it than me the last couple of months while I've been very focused on a new, extremely exciting project that will soon see the light of day (stay tuned!).
I'm also glad that EPiServer is doing this because there are certain things that Page Type Builder would never be able to do, or do as nicely, as a native implementation could. Clearly a good native implementation is better than a library that tries to change the workflow of an existing application.
But, I'm also quite scared. When EPiServer ships with functionality similar to PTB's it means that most developers will use it, even if it's not well thought out or limited compared to PTB. That's just how it is, especially in the world of Microsoft/.NET development. That's all good and well given that the native solution is good. But if it isn't, it means that the native solution kills a lot of the interest in the open source solution, making it harder for the open source solution to receive feedback and contributions.
Hopefully that won't be an issue. There are really great developers working at EPiServer. But, one thing worries me, and that is how this was announced. I had no idea this was going on and it seems few outside EPiServer did. While I don't think EPiServer would have much to gain from asking me about how to implement their solution, they probably could have gained from asking me about what problems developers in the community have asked for Page Type Builder to solve. In my opinion, feedback from real users (developers in this case) is essential to all software development and building solutions in isolation almost never works (unless you're Apple). Just think about the first version of Entity Framework.
Anyhow, I really hope that their implementation is good, for all our sakes. And if it is, no one is happier than me :)
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
Andreas R 9 months ago
Im aslo conserned about what will happend to PTB when the native support for typed page types is released. Hopefully we can still keep it alive so we can keep using it on all those sites that has been built with PTB at least.
I hope you will be at the seminar asking some hard questions :)
Peter Sunna 9 months ago
Joel, thanks for your feedback.
We have been talking to developers, site owners, editors, marketers, etc to collect the right user problem set that we want to solve in Falcon. Now, after analyzing the market problems and running research projects during the summer we want your input on the developer side of things.
I think everyone got the the feeling that we were almost done and just wanted to give you the good (?) news. The fact is that we are in very early stages, not even started coded yet, and want to know if we're trying to solve the right problems. As you are aware of we have been using this technique for other parts of Falcon. We got some great feedback, however mostly from developers within the same "persona". We felt that we wanted to reach out to a broader audience this time since a feature like typed page data will be something that all developers, beginners as well as Jedi masters like yourself, will use all the time when building sites.
We will follow up with smaller focus groups to get more detailed feedback. The feedback from you and other core PTB developers are of highest value to us.
Peter Sunna
Product Manager, EPiServer
Lee Crowe 9 months ago
Hey Peter
It's good to hear that you will be getting feedback from the community to get the a broad base of developer requirements.
PageTypeBuilder has really improved the development experience while using EPiServer and we would like a native solution to be equally as good or better.
I think there is high value as Joel suggested in consulting with him as the community has been badgering him for months with various feature requests.
Lee Crowe
Martin Odhelius 8 months ago
Personally I think it would have been better if EPiServer fist would try to fix the shortcomings that you try to fix with EPiAbstractions rather than to do their own implementation of PTB. And why do not EPiServer just contribute to PTB rather than to build the wheel again?
Henrik Nyström 7 months ago
Martin,
You might be pleased to hear that we (as in the devs at EPiServer) are not only working on strongly typed page data, but that we are also adding a lot of abstractions to our code base as well.
As to building it into the main product rather that just contributing to PTB, a lot of people have strongly argued the opposite to us, saying that it needs to be in the CMS.
We felt that by implementing strongly typed data support natively we had an opportunity to improve some things in ways that otherwise wouldn't be possible and also make use of this feature inside the CMS and other products as well.
As for contributing I believe that there are a number of developers at EPiServer that has contributed to the PTB project in some way.
Best regards
Henrik Nyström,
Developer, EPiServer
Martin Odhelius 7 months ago
"We felt that by implementing strongly typed data support natively we had an opportunity to improve some things in ways that otherwise wouldn't be possible"
To be honest this sounds like the exact same shortcoming to me: that it needs to separate is concerns, strive to cut all unnecessary cross cutting concerns and be more abstracted, mobilizable and plugable.
If it is not possible to do Typed Page Data without build it "inside" the core product it really sound like the CMS still isn't that abstracted that it should be.
I like to write unit tests for my code which means that i have to be able to fake external dependencies, I also like to write my code with dependency injection and using IoC-containers to manage my dependencies. To be able to do this it takes that the code is abstracted and has separates its concerns OR you have to write adapters or facades for your external non so abstracted dependencies. And when working with EPiServer 6 today I can say that I have to spend pretty much time to write adapters and facades. I really hope you are right when you are saying that you are working on it, but when you say that you have to build Typed Page Data inside the core I'm starting to get a bit suspicious ;)
"a lot of people have strongly argued the opposite to us"
And what has been their reasons? The only reason I can see why anyone should demand this is because they want a guarantor for support of the product which isn't always the case with all open source projects, but that would probably be pretty easy to solve in this case, EPiServer could just say that they will support and contribute to PTB and that it will be an "official" module and ship it with the product OR EPiServer can do their own fork of it and make it their version as long as the fork follow the original license.
Henrik Nyström 7 months ago
Martin,
As you probably are aware we also need to consider how the current code base is used today and keep a certain level of backwards compatibility. Creating a solution that overnight separates every concern, doesn't have any cross cutting concerns and are fully abstracted and pluggable has it's challenges, so I believe that you are best to keep beeing suspicious.
Of cource it is possible to do typed page data outside of the product as Joel has showed and showed in a great way, but we felt that it was impossible to do it outside in the way that we wanted it. Hopefully this will make more sense once the release is public.
I also understand what you are saying about writing abstractions and fakes and we are working on making things more abstracted to make things easier for framework users. But then again you could argue that the best solution is to always code against your own abstractions when working with third party libraries.
Martin Odhelius 7 months ago
"Hopefully this will make more sense once the release is public."
Hopefully, but I heard almost the same thing when you introduced the dynamic data store as well. Before it was released I saw a presentation about it with Peter Sunna, and I was a bit surprised that EPiServer was going to build such a thing when it already exist very well-recognized and generic products as that, so I asked Peter why, and he said that the existing ones couldn't do the things that DDS can but he couldn't tell me exactly what. That is maybe true but I can not even today see what those features are and why you not used for example SubSonic SimpleRepository instead that generates generic databases without any tight coupling to even itself so you can easily use the data both with or without SubSonic, and the best thing of all is that it is released under a BSD license so you can practically do whatever you want with it.
It can sometimes happen (out of unawareness and because it is so easily accessible when you already is in EPiServer) that some of my developers uses the DDS even to storing data that is not tightly coupled to EPiServer itself (user data, application data etc). If we later on need to use that application or data in another place outside the EPiServer environment we get huge problems. We suddenly have a tightly coupling to the huge EPiServer database and to a very specific bigtable design that is very hard to fetch data from without doing it via an entire EPiServer installation and all what it means. DSS may be good to use when you shall save tight coupled EPiServer data (cms settings, plugin settings and so on) but it was introduced as a data store for any data which I think is both dangerous and encourage of bad design which lead to even more coupling.
Well, I got a bit off topic here, but the only thing I would like to say was that coupling is a developers (and its customers) worst enemy. But I can realize that a page type builder can benefit from being a core function, but the thing I see here is that we have a very well written and designed module already (probably the best EPiServer-related module I have ever seen) that a lot of developers already are using (I would say it has started to become defacto, at least at my company) and now you are going to rewrite this from scratch, is it really so strange that I get a bit suspicions ;) Anyway, I hope you will prove me wrong :)
"you could argue that the best solution is to always code against your own abstractions when working with third party libraries."
You shall minimize the borders (as Uncle Bob say in his book Clean Code) but you of course also want to be able to write tests for the code at the borders if possible, and if all classes in the external libs are inheriting from interfaces that is often just enough. So one easy interim way to do it could be to put interfaces on all your classes and then make a shadow api where all methods and parameters make use of them instead of the concrete classes.
Andrey 7 months ago
The only thing that scares me in native support is that it won't be open source. Every project I've worked on had a modified version of PTB. Firstly it was support of interfaces inheritance, and now its container pages support.
Maybe EPiServer team won't have such a problems because features will be consistent with each other, but I really doubt that (looking at XForms - feature seams to be FAR from done, but its in release).