The Smartsite Virtual Path Provider

Virtual Path Providers were introduced in ASP.Net 2.0. They implement an extra layer through which the ASP.Net runtime accesses the file system.

Smartsite iXperion has a built-in Virtual Path Provider (VPP), which allows ASP.NET to load rendered pages from Smartsite just as if it were a file system. The VPP is particularly crucial for the Smartsite ASP.NET integration.

The Smartsite VPP has a few interesting features:

Friendly Url recognition

Virtual Path Providers are associated with a virtual directory prefix. The Smartsite VPP is normally associated with the cmsvp prefix, but the prefix can be configured in the Smartsite.config, under AppSettings:

XML CopyCode image Copy Code
<add key="VirtualPathPrefix" value="cmsvp" />
To let ASP.NET load virtual files from iXperion, simply use the following syntax: 
  CopyCode image Copy Code
Even better, any friendly url passed after the prefix will also do:
  CopyCode image Copy Code

Automatic kick-in for ASP.NET applications

For ultimate transparency, incoming Urls to ASP.NET applications in the CMS will now automatically be mapped internally to the VPP, using Url rewriting. This way, friendly urls generated by Smartsite will work regardless of whether the Smartsite Publication Server or ASP.NET is in charge:

  CopyCode image Copy Code
We call this principle Native ASP.NET Pages (NAP).

Cache Dependencies

Especially when ASP.NET 'files' are loaded through the VPP, caching the Smartsite data becomes crucial, because of ASP.NET's compilation model. When files are modified on disk, ASP.NET automatically recompiles them. This behavior also goes for (VPP) Smartsite 'files', except that a Smartsite 'file' does not exist, but is assembled dynamically during rendering.  This is why the VPP caches them. If not, ASP.NET would recompile them at every request, which would kill performance. The VPP cache mechanism is built around a so-called Cache dependepency system. The Smartsite VPP will create a CmsCacheDependency object that is triggered whenever an affecting content change occurs. The CmsCacheDependency objects in fact register themselves with AIM. AIM gets signalled when a CMS change occurs, and propagates the change to all registered clients, including the VPP CmsCacheDependency objects.