CustomPageStore - A way to integrate external data with EPiServer

by: Johan Björnfot

For some time ago we got some requirement list from a new potential customer. They have a lot (millions) of existing data items that they would like to present through EPiServer, the question for us was how they could achieve this.

One approach (that exist today) is to either extend our FURL module (by event handling) or write an own httpModule to get "common" urls and do the routing between EPiServer pages and external data. Then they would also need to write custom navigation controls, edit plugins etc to make it work.

The other approach we came up with was to get the content into EPiServer in a lower layer  and let the data appear as PageData objects. The nice thing with this approach would be that then the data would be handled automatically in the higher layers such as GUI  since they would see the data as EPiServer pages. This approach is what I here after refer to as "CustomPageStore".

One idea of how to implement the CustomPageStore approach would be to have a base class with methods like GetPage, SavePage, DeletePage etc. which a custom implementer would inherit from and extend. Then it would be up to the implementer to choose how tight the integration with the external system will be. To get content in to EPiServer in a read-only way it will probably be sufficient to override methods like GetPage and GetChildren. And in the other hand if all methods are handled then there will be possible to get a very deep integration where editors would be able to create/edit/delete content in the external system through EPiServer. The intention with such an implementation from our side would be to give custom implementers possibility to handle security, multi language, page versions, page URLs, caching etc.

Currently this is something we think is interesting and is investigating.

Please post comments if you have any ideas/suggestions of what you would expect/like for such an integration point.

04 April 2008


Comments

  1. Sounds interesting. But if the potential customer had millions of data items would it be smart to load this into the episerver page tree?
  2. This is a brilliant idea, and I can see lots of use cases for it. Lars' comment is a good one, as this could potentially lead to developers creating adapters that load lots and lots of pages on the same level. Perhaps a way to tell the tree to not expand as normal, but show a search/filter UI in the EditPane instead?
  3. The idea is that the custom implementer can have their own structure of their data. Then when expanding nodes in the edit tree no more data than exist at that level would be fetched to EPiServer at that time (the pages could be cached after fetched).

    Then it would really be up to the implementer of a custom plugin to make sure the data is structured well (that is not millions of pages at the same level). But as Steve pointed out perhaps we could handled unstrucured data as well (that would though require changes in the Edit tree as well).

  4. This sounds very interesting. Personally i dislike the way the Edit tree works. We work with some huge sites and it really make no sense to load an entire page data object when expanding a news archive node, for instance, with 100+ page items. When all you really need is ACL, page name, created date etc.
Post a comment    
User verification Image for user verification  
Johan Björnfot

About me

Developer in Backend Team/Product Devlopment


Syndications


Archive


Tag cloud

EPiTrace logger