At a high-level there are about 10 ways you can integrate with Morphfolia; this article gives an overview of these options. All of the integration options here are possible without having to modify Morphfolia itself (with the exception of configuration).
Here’s a diagram for context (detailed information to follow beneath). In the center are the main Morphfolia packages and classes that integrators will probably want (or need) to work with – depending on which approach you want to take. The blue packages and classes on the sides represent code you might write yourself; with association lines showing the main integration relationships. (Note the word ‘package’ comes from UML – where it refers to a logic group of items, in this article package also often refers to an assembly).
Click image for a full-size copy (1516 x 1292 pixels, 272Kb)
Click image for a full-size copy (1516 x 1292 pixels, 272Kb)
Let’s go through the 10 options in more depth.
(1) Develop your own website (ASP.NET / ASP.NET MVC) and leverage Morphfolias APIs
The basic idea is to use Morphfolia as a base – rather than starting with a new blank ASP.NET Web Application project; however, you can still use a new blank project if that’s easier for your situation and then leverage the Morphfolia packages and classes that are useful to you.
As shown on the diagram, the Publishing System is possibly what you’re after – although you can leverage pretty much anything (Business Logic, WebControls, Data Access and so on).
(2) Use the Web.Config to route requests to your HttpHandlers, which can also leverage Morpfolia APIs
A lot of flexibility comes from the web.config: direct Http Requests to the mechanism best suited to handling them: could be Microsofts out-of-the-box ASP.NET WebForm handler (System.Web.UI.PageHandlerFactory), Morphfolia’s default HttpHandler or one you’ve developed yourself.
Your HttpHandler can then leverage various packages and classes in Morphfolia. As per the diagram you’ll probably want to use the Publishing System but there’s nothing stopping you using the Business Logic (Http Logging, the CustomPropertyHelper, etc) and other packages.
(3) WebForms (and other things) can use the WebFormHelper
The WebFormHelper was specifically designed to work with WebForms, but may also be useful with any MasterPages and UserControls that you write yourself. For more info on how you use the WebFormHelper with WebForms see: Using in an ASP.NET WebForm.
In essence the WebFormHelper can be used in “code behind” and “in-line” as per options 4 and 5 below, the thing that makes it worthy as an integration option in it’s own right is that it’s specifically designed for use with WebForms – allowing you to easily perform common Morphfolia / WebForm integration tasks.
(4) Your MasterPage, WebForm or UserControl views call functionality using in-line code
For example, here’s an example of using the WebForm helper “inline” in a .aspx page which uses a master page; you could do the same thing in the MasterPage itself, or a UserControl. Just be careful where you call the HttpLogger (don’t call it more than once per pageload).
(5) Your code behind or WebControls call functionality in the Publishing System
You can also (as you’d expect) use the Morphfolia API’s from the code behind in MasterPages (as shown here), WebForms, UserControls and in WebControls.
(6) Your code behind calls Morphfolia Business Logic
The Publishing System (including the WebFormHelper) exist to bring consistency to your site or application – by allowing you to skin WebForms and ‘content’ from Morphfolia using the same underlying mechanisms (PageLayouts and so on).
Another option available to you is to go straight to the Business Logic and use the APIs in a more isolated manner (rather than using the ‘normal’ Morphfolia website (with it’s publishing section and so on). Although it depends what you’re aiming to do you might want to do this to leverage:
- The CustomPropertyHelper or StaticCustomPropertyHelper
- The ContentIndexer or SearchEngine
- Or maybe just the Constants
Using the Business Logic APIs you can create WebForms that go straight to whatever core functionality you want.
(7) Serve up your WebControls via HttpHandlers
The default HttpHandler provide with Morphfolia is responsible for serving the majority of user facing pages, including both administrator defined content and the ‘special’ pages (Search Results, Site Map and Site Index); all of these special pages simply creat an instance of a WebControl and write it to the output stream.
You can do this by modifiying the default HttpHandler or writing your own (use the default one as a starting point). Here’s how the default HttpHandler does it (in this case to serve out a TagCloud, which the current pageLayout will place where ever it’s been told to); the default Httphandler uses a simple switch statement that checks the PageName and instansiates a particular WebControl as required:
And in case you’re wondering, this is (basically) how you get an HttpHandler to serve up a WebControl:
(8) Your WebControls can leverage morphfolias Business Logic APIs
This is bascially the same as Option 6, except that by using WebControls your functionality can be easily re-used in multiple systems, and can also be served out through HttpHandlers (option 7).
(9) Your Business Logic calls the Morphfolia Business Logic
You can also work at the Business Logic level; develop a complex application of your own that uses some of the logic in Morphfolia. You can, of course, also call the logging methods provided in the Buisness Logic – or the under-lying methods in the Common assembly; this will help isolate changes in the logging providers (the MS Enterprise Libraries).
(10) You Business Logic calls the Morphfolia Data Provider via its Interface
If you like the MS SQL DataProvider you can call it directly (preferably via the interfaces located in the IDataProvider assembly)
- There are a variety of Helper classes in the Publishing System, Business Logic and Common assembilies; they’ve mostly been written with the intent of being used by external code.
- The one major integration point missing is a WebService facade. There currently aren’t any plans to develop a WebService facade in the immediate future – although this would change if enough people contact me asking for it 🙂