Native ASP.NET Pages
With Native ASP.NET pages (NAP), ASP.NET data is stored in CMS items using the filetype field to specify the ASP.NET type, such as .aspx.
How NAP works
Let's assume we select .aspx as the file type. When a request comes in on the web server, the file extension will trigger the ASP.NET page HttpHandler, not the Smartsite one. To make ASP.NET call into Smartsite, NAP uses URL rewriting to insert the Smartsite Virtual Path Provider (VPP) prefix. This will then force ASP.NET to call into the Smartsite VPP when loading the (virtual) file. The output of the Smartsite VPP request is then taken as file input for ASP.NET and further processing is identical to 'normal' ASP.NET files on disk.
NAP benefits
- No redirection or Master Pages are needed to glue ASP.NET and Smartsite together.
- full Smartsite Friendly Url support for ASP.NET applications (when stored in the CMS), thus completely transparent to the end-user.
- Full contextual rendering of all Smartsite logic (item metadata, hierarchy, relations).
This is what the NAP process flow looks like:
Incorporating ASP.NET code
Now, if we simply store ASP.NET pages in Smartsite CMS items, we'll have to store ASP.NET markup somewhere...
Several methods can be used to accomplish this:
In-line markup
The simplest way to ASP.NET-enable Smartsite items is to just type it in. The only problem we'll have to overcome is avoiding Smartsite choking on the unknown ASP.NET tag soup.
This is relatively easy: just use a container macro such as text or region with a CDATA block to wrap ASP.NET code:
| Smartsite SXML |
Copy Code
|
|---|---|
<se:region>
<![CDATA[
<% = DateTime.Now() %>
]]>
</se:region>
|
|
Including application blocks
To make working with ASP.NET code easier and cleaner, RC2 comes with a new macro, application:
| Smartsite SXML |
Copy Code
|
|---|---|
<se:application location="/apps/myapp.aspx" id="app" /> |
|
| Smartsite SXML |
Copy Code
|
|---|---|
{page.app.render("block1")}
|
|
| HTML |
Copy Code
|
|---|---|
<asp:Content runat="server" ContentPlaceHolderID="block1"> (...) </asp:Content> |
|
This makes debugging ASP.NET code easier, since the same file can be used in combination with a (fake) master page.
Header directives
The ASP.NET item logic must contain a mandatory placeholder declaration with id attribute equal to "directives".
| Smartsite SXML |
Copy Code
|
|---|---|
<se:placeholder id="directives" /> |
|
Include this placeholder declaration in the NAP item or rendertemplate logic, before all other output. iXPerion will emit a dynamically generated ASP.NET header at the position of this placeholder, based on the data added to the placeholder.
Filetype
NAP items require a friendly name with file extension ".aspx" and a specific file type with the following configuration:
Item requests to NAP pages must specify the friendly url of the requested item. The HttpHandler sends requests for items with the aspx file extension to the ASP.NET render engine. If an NAP item request does not specify the aspx file extension (e.g. based on the item id), then the contained ASP.NET statements are not evaluated but emitted as-is to the output.
Conclusion
Integrating ASP.NET and iXperion using NAP provides:
- Great separation of content, style and business logic.
Every aspect of the development process is placed in the hands of the right responsible team. - Maximum flexibility for site developers.
They can use all the richness of the ASP.NET framework, including ASP.NET AJAX and third-party webcontrols. - Corporate identity protection.
using Smartsite Render Templates and Translations, with all the richness of Smartsite iXperion SXML, versioning, workflow, role based management. - Leverage existing knowledge
With NAP, few people need to be trained specifically to use it. - Easy deployment.
Smartsite provides everything that's needed. Just set the file type of a page to .aspx and off you go. - Future proof
NAP provides a robust model with few dependencies. Future enhancements in both ASP.NET and iXperion are not expected to break the concept.
Note: You may come across errors of the form: "The VirtualPathProvider returned a VirtualFile object with VirtualPath set to '/foo/bar.aspx' instead of the expected '//foo/bar.aspx'". This occurs when the aspx file cannot be compiled.
Please see Microsoft Bug #307978: ASP.NET is erroneously replacing page compilation errors with the bad virtual path error.
Also see A Workaround For VirtualPath Weirdness With Custom VirtualPathProviders.