It's best to implement your custom features as separate projects in your own Visual Studio solution, rather than adding to the existing mojoPortal projects. Start by copying one of the mojoportal solution files (mojoportal-core.sln for example) and rename it. Now you can add your own custom projects to this solution. Doing this makes it easier to stay up to date with the latest mojoPortal source code from the repository. You'll be able to update the mojoPortal source without it touching your custom code. If you find something that needs to be changed in the mojoPortal code in order to support your feature, consider submitting the change back to the project.

For more information see Setting Up a Solution for Custom Development.

Implementing a new feature that plugs in to the content system in mojoPortal is relatively straight forward . Features can be very simple, involving only 1 module control (see the ContactForm.ascx module in mojoPortal.Features for a simple example) or more complex, requiring any number of supporting .aspx pages in addition to the module control (see the ForumModule.ascx and Forum*.aspx pages in mojoPortal.Features for a more complex example).

Every feature should have 1 (and usually only 1) ModuleControl, which inherits from mojoPortal.Web.SiteModuleControl. This is the part that plugs into the mojoPortal content management system and allows you to put an instance of your feature on the content system page. Instances of this ModuleControl can be placed on page(s) along with ModuleControls from other features such as the HTML Content Module, Links Module etc. For a simple feature the ModuleControl may be all that is needed.

Important: When developing features that will use postback right in the UserControl/SiteModuleControl of the feature, you typically will need to call

Page.EnableViewState = true;

in page load or init because we set it to false by default to avoid viewstate when it is not needed.

Notice that in mojoPortal, all the pages in the menu are derived from the database and don't actually correspond to any physical .aspx pages. There is actually only one page that handles requests for all these content pages and that page is Default.aspx. This page knows what content page to display based on a query string parameter pageid, so the actual url is always Default.aspx?pageid=x where x is replaced with a pageid corresponding to a page in the database. Since we use URL re-writing to make friendly urls, you normally do not see Default.aspx?pageid=x but instead see something like home.aspx or forums.aspx. Under the hood, these friendly urls map to Default.aspx?pageid=x

So the ModuleControls are loaded into the page based on data from the database which captures the feature module instances that the content author has placed on the page. For more complex features like the forums, the ModuleControl links to supporting .aspx pages like ForumView.aspx, ForumThreadView.aspx, ForumPostEdit.aspx, etc. These pages are actual physical .aspx pages that are not linked directly from the menu. You can think of the ModuleControl as the entry point to a feature, but the feature does not have to be fully implemented within the Module Control. It can have as many supporting pages as needed so that very complex features may be implemented. Your module control must know how to link to those supporting pages.

To implement a Module Control, you just create a User Control by right clicking a folder in Visual Studio Solution Explorer and choose Add > New Item...>Web User Control. Then you need to modify the User Control so that it inherits from mojoPortal.Web.SiteModuleControl.  If your feature needs supporting pages, you need to make those inherit from mojoPortal.Web.mojoBasePage. You can refer to existing features for examples of how this is wired up. You could even copy an existing ModuleControl and supporting page and modify it to start your own feature.

Inheriting from mojoPortal.Web.SiteModuleControl is what allows your feature to plug into the content management system of mojoPortal. It also provides a simple implementation of IWebPart, which allows the module control to be exposed as a WebPart. In mojoPortal, the MyPage feature utilizes WebParts to provide user personalizable pages. In the Module Settings for any module instance you can check the box that says "Available for MyPage" and this will make the module instance available in the WebPart catalog so users can add it to their personalized page(s) under MyPage. So by inheriting from SiteModuleControl your feature will be able to be added to personalized pages as a WebPart.

Updated 2007-09-04 by Joe Audette
Updated 2012-01-12 by Jamie Eubanks

Rate this Content 14 Votes