November Happy Hour will be moved to Thursday December 5th.
AI OnAI Off
Design Question; Custom Page Provider
EPiServer don't provide much guidance on patterns, but I would represent this data as custom properties rather than sub-classing the PageData object.
IMHO, this is a cleaner approach as all the information that you need on the page will be available through the standard EPiServer property API.
It also means that all the code that interfaces directly with your data source will be encapsulated in the page provider itself.
Ben.
Oct 05, 2009 19:14
Ben, thanks for answering! It seems that not many people have tried to make their own PageProvider yet when asking around.
I must say that I agree with you and it's also the solution I choose from the beginning. Then I got some second thoughs when it meant creating Custom Properties when I really not needed to.
The good thing though is that if we in the future want to be able to edit the pages and/or use them in a different Page Provider, I have already created the properties.
Oct 06, 2009 11:37
I have one issue that I am arguing with myself alot when it comes to building a Custom Page Provider.
I'd like to hear other developers take on this question;
When you for an example make an Page Provider of a Product Database, should you make SpecializedProperties to handle your own complex properties (Even though they will never be edited in epi, so no need for a PropertyControl), this way in the website itself only need to work against basic episerver handling without knowledge of the product database and it's models.
OR
Create a subclass of PageData (like a ProductPageData) which will contain your own models with data from the database.
Both have their own advantages. The first one's main disadvantage is that you'll have to create a number of Specialized Properties that isn't used in their originally meant purpose.
This question only aplies if you shouldn't be able to edit the pages from the provider.