When developing custom features for mojoPortal I realized that there are some difficulties in doing this.
They are not critical when customizing a site for particular client, but really prevent people from publishing custom features that can be installed on many sites. Let me try to explain what these difficulties are. As there are no external modules now, I shall try to consider built in modules as external for examples.
1. By the way, what is the feature? It consists of:
- Several modules that can be plugged into the content system and/or several web parts and/or several aspx pages. There are also some static objects like images and css files. For example, in case of built in Forum feature, it is one module and several aspx pages.
- One or more localizable resource files containig strings in different languages
- Some feature-level properties like "ForumThreadImage" (now stored partially in web.config, partially in resources.resx)
- Definitions of some module-level properties like "ForumEnableRSSAtForumLevel" (now stored in the database and can be edited on Admin/ModuleDefinitionSettings.aspx)
- Localizable names for the module-level properties (now they are to be in resources.resx for all features)
- Values of the module-level properties (stored in the database, really no problem with them)
- Some database objects including tables and stored procedures
- Some code (most likely already in one or more dll files)
2. The first problem is that there is no simple way to install/uninstall a whole feature. When you are developing it, you just add projects to the mojoPortal solution, recompile, copy the required files in the post-built event, add proprties directly to the database or through the web interface and so on.
But this approach does not really work when you try to redistribute your feature. You need to write a many-pages manual on how to install it (where to copy all the files, how to modify web.config, what modules and properties to add through admin interface, what objects to add to the database for all the data layers supported, ...). As the procedure is rather complicated, it's hard to produce it and very simple to make a mistake when performing these actions. In my opinion it's the main problem that prevents people from developing custom features for mojoPortal.
3. Also there are some architectural difficulties when trying to implement automatic install of a custom feature:
- Now it's supposed that one feature is one .ascx file and nothing else. There is no way to control all the other files
- There is no simple way to store feature-level properties for external modules (localizable resources is not a good place to do this, and the portal's web.config file does not contain them as it does it now for built in features)
- Localizable names for the module-level properties are all supposed to be located in the main portal's resource file (resources.resx). So, without modifying portal resources there is no way to add any module-level property to the custom feature
In my opinion, the feature module system is to be somehow changed in order to address the problems mentioned. In this case it will be much easier to add features to the portal.