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
I just released version 0.9 of Page Type Builder. This version is also the release candidate for, or at least the beta version of, version 1.0 in the sense that I don’t foresee any new features in version 1.0, only bug fixes (if needed) and possibly some minor tweaks.
The focus for this version has been to improve the performance at startup, which has been seriously improved. I have also added more validation at startup and more informative error message.
The one new feature that has been added is two overloads of the GetPropertyValue method. These overloads accepts a boolean parameter named includeDynamicPropertyValue. Set it to true and the method will not just return values set explicitly for the page but will also check if there is a matching dynamic property value if no value is set for the property on the page.
I made a decision that version 1.0 should only contain the core features needed for page type inheritance and strongly typed property access. I have quite a lot of ideas my self for other features that would be nice to have, and I have also gotten a lot of ideas from the community. These include an admin interface for performing updates to page types and properties that Page Type Builder doesn’t do, such as removing properties that are no longer declared in code. Other such features include adding strongly typed access to the built in properties in the base class for typed PageData objects and extension methods for DataFactory. Many of these things would be great to have but are not really at the core of what PTB should do so I leave them to a future “extensions library”.
As usual the release can be downloaded from the projects site at CodePlex.
As always I greatly appreciate any and all feedback. As this release can be considered a release candidate for version 1.0 I’m especially interested in bug reports and reports of features that doesn’t seem to be working as they should. Currently the only thing I know should be done is reviewing the projects interface, that is what methods are named and which ones are public or internal.
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
Martin S. 2 years ago
Joel, this is as you know damn good stuff. Keep it up, looking forward to version 1.0!
Henrik Nystrom 2 years ago
Hi Joel,
Great job with the PTB so far! Have started using it on a client project and found a few potential issues, but I assume that you rather want them registered on the Codeplex site instead?
Also, what's your plan around Dynamic Properties? I can't really see the problem with specifying them in the same way as PageTypeProperties but with a different attribute? I can see myself adding them to a base pagedata object.
I would also suggest some kind of configuration where I could control (just turn off?) the automatic loading. I know it's consistent with how the EPiServer plugins work, but I would hate to have left a dll by mistake on a production server and it loads up 20+ extra page types that I need to remove manually. This could also be used to control if any definitions should be removed.
Regarding API naming I found that the use of the word 'Definition' was a bit inconsistently used (i.e. Tab, TabDefinitionUpdater, TabLocator).
I also would not use the name "includeDynamicPropertyValue" but something like "usePropertyGetHandler" since that can be overriden to do other things than including Dynamic Properties, although it's the default :)
Finally, have you looked into replacing the LoadCurrentPage page extension and the CurrentPageHandler on the Page instead of the current structure where you use your CurrentPageRetriever on every call to the CurrentPage property. It seems like you could save a lot of type checking that way.
Again, great work Joel!!
Cheers
Joel Abrahamsson 2 years ago
Henrik, thanks for your input! I'll try to answer everything :)
"Great job with the PTB so far! Have started using it on a client project and found a few potential issues, but I assume that you rather want them registered on the Codeplex site instead?"
Both here and there works fine :)
"Also, what's your plan around Dynamic Properties? I can't really see the problem with specifying them in the same way as PageTypeProperties but with a different attribute? I can see myself adding them to a base pagedata object."
This is something that I've thought about quite a lot and discussed with others. There are a couple of reasons for why I haven't implemented this feature. First of all there isn't really any natural place to put the declarations and checking that each property is only declared once would take quite a lot of work and code while its easy to add new dynamic properties in admin mode. At the same time I think the usage of dynamic properties should be discouraged, so if someone actually adds a dynamic property I think its good that they will have to do something totally different (going in to adminmode) compared to adding a regular property.
Typing this I realize that my arguments aren't very convincing, so, let's say: maybe in a future version :)
"I would also suggest some kind of configuration where I could control (just turn off?) the automatic loading. I know it's consistent with how the EPiServer plugins work, but I would hate to have left a dll by mistake on a production server and it loads up 20+ extra page types that I need to remove manually. This could also be used to control if any definitions should be removed."
Ahh, another thing that has been discussed a lot :) The problem with a configuration file is that just like you could forget to remove an old DLL from the server you could also forget to remove/change the configuration. For now I think its better to keep it as simple as possible, that is PTB does what PTB does :) With that said I think its definetly something worth looking at in the future.
"Regarding API naming I found that the use of the word 'Definition' was a bit inconsistently used (i.e. Tab, TabDefinitionUpdater, TabLocator)."
No kidding :) The problem is that EPiServer uses it inconsistently to (PageType, PageDefinition, TabDefinition) which reflects in PTB. I'll look into better names, but its hard.
"I also would not use the name "includeDynamicPropertyValue" but something like "usePropertyGetHandler" since that can be overriden to do other things than including Dynamic Properties, although it's the default"
Definetly! I'll fix that.
"Finally, have you looked into replacing the LoadCurrentPage page extension and the CurrentPageHandler on the Page instead of the current structure where you use your CurrentPageRetriever on every call to the CurrentPage property. It seems like you could save a lot of type checking that way."
I'm not quite sure what you mean. Could you give me an example? The CurrentPageRetriever class is just holder for the GetCurrentPage method which body would otherwise be duplicated in the four different base classes for pages, but I'm guessing I'm missing your point :)
Again, thanks for the feedback! Keep it coming!
Henrik Nystrom 2 years ago
Regarding Dynamic Properties:
I agree that your arguments aren't that convincing ;) But I can understand that it's not a highest priority. I might give it a quick go myself...
Regarding configuration:
I'm not suggesting to have a configuration file, but rather that you could have an optional section in web.config. Again, I might give it a go myself...
Regarding retrieving the CurrentPage:
I understand your reasoning behind the CurrentPageRetriever, but if you look at the page base classes, every time you call CurrentPage, it will go off to the DataFactory and then do the type checking before returning the TypedPageData. And the CurrentPage property is potentially used quite a lot. Therefore I looked into how EPiServer populates the CurrentPage in their classes and realized they used a PageExtension (LoadCurrentPage) to load the CurrentPage behind the scenes. My thought was therefor that you could create your own PageExtension that replace the LoadCurrentPage and you should them be able to just cast the base CurrentPage property to the Typed version without the extra load and type check. It's just a theory so far however, I should probably have tried it out first, so I might give that a go... ;)
And your right, your notification doesn't work that good...
Joel Abrahamsson 2 years ago
Again thanks for the feedback Henrik!
Regarding Dynamic Properties:
I've given this quite a lot of thought and following the less-is-more principle I'm not sure it belongs in PTB as it would cause quite a lot of extra code to implement as a lot of validation would have to be done and at the same time it would be quite easy to ensure that a dynamic property exists in the Application_Start event in global.asax. A utility method for doing so would however be easy to ship with PTB.
Regarding configuration:
I'm not sure I can think of a realistic scenario when this would be useful, but I'm definitely open to the idea. I have however tried to follow the less-is-more principle with PTB, but if it turns out that this is something a lot of developers want I'll definitely add it.
Regarding retrieving the CurrentPage:
Looking at how EPiServer normally retrieves the current page it retrieves it from DataFactory (in the LoadCurrentPage class). CurrentPageRetriever does basically the same thing. That is it retrieves the page link from the CurrentPageHandler and then retrieves the page from DataFactory. Finally it checks that it's of the correct type and casts it to the specified type. So both ways causes one call to DataFactory. The type checking is really not needed but I think the extremely slight overhead it incurs is worth it considering that we as developers will get a better error message when the page is of the wrong type. Again, I might misunderstand what you mean though.
Damn notifications :( Luckily I'll soon switch blogging plattform and hosting to EPi though :)
Henrik Nystrom 2 years ago
Regarding retrieving the CurrentPage:
I guess it's really splitting hairs, but the small difference is that the CurrentPageHandler can save the retrieved PageData in a local field since it handles the set property as well, but with your construct it goes off to the DataFactory and does a type check every time you access the CurrentPage property.
Joel Abrahamsson 2 years ago
Ahh, yeah, you are right of course. I'm slightly retarded at times ;)