Custom features for mojoPortal

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
5/25/2007 7:49:32 AM
Total Posts 488

Custom features for mojoPortal

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.

5/25/2007 8:17:16 AM
Total Posts 18439

Re: Custom features for mojoPortal

Hi Alexander,

I am indeed thinking about these things and how to make it easier to configure which features get "installed" in a site.

Development of external modules is not difficult and there is a good example if you open the WebStore.sln, the e-commerce feature is a complex feature and is implemented as separate external projects. It uses post build events to deploy dlls, resource files, .ascx, and .aspx files to the correct location beneath the web. The only downside in development is that you have to rebuild even if you only made a change in a .ascx or .aspx files. The reason you have to rebuild is so the files get copied by the post build event.

When we talk about installing a feature there are 2 levels at which we discuss it, installing on the server and installing in the site.

Installing on the server requires xcopy deployment which is not difficult though yes it requires instructions and copying to a few locations. I do not think it is a good idea to try and implement a web based installer for deploying features on the server because then the web app would have to run with permission to write files in locations like the bin folder which is a very bad idea.

Once a feature is installed on the server installing or uninstalling from the site is a simple matter and a web ui can be used. Every feature needs a .ascx file (inheriting from SiteModuleControl), a simple feature can be only that but more complex features require separate pages. the .ascx file is simply the entry point to the feature and it can plug into the content system framework. From there it should know how to link to its own supporting pages which are outside the content system pages.



5/25/2007 8:29:17 AM
Total Posts 18439

Re: Custom features for mojoPortal

A few things that I see that do need improving are:

1. We need an easier way of configuring how module settings are added

2. As you pointed out I think, we need to be able to specify a resource file where to get the label for the module setting, currently it expects them in the main resource file.

I have plans to solve these.

However I would point out that the current ModuleSettings page is just a convenience of where to store settings that govern the feature but nothing prevents a developer from implementing a different configuration settings for their own feature. Like in the e-commerce feature I could have stored all the settings in module settings but instead decided to make a config page for WebStore settings because I have a lot more complex settings.


5/29/2007 7:00:04 AM
Total Posts 488

Re: Custom features for mojoPortal


I think I was a little bit missunderstood. It is not difficult to develop a feature. I think it difficult to develop a feature that can be easily installed to the production site.

Even with the web store feature, there is no way to deploy it to producton other than just checkout svn sources (including sources of the portal), rebuild and reupload the whole portal. Even in this case I do not understand how the required database objects will be created in the production database. And what if I want to install several custom features - do I need to create a custom solution including all of them?

If installing a feature can somehow be performed using post-build events, uninstalling the whole feature is really impossible now.


You are right about security perposes. But you already have some features that require some extra permissions: automatic db upgrade and file manager. So, implementing automatic database object creation/upgrade/deletion for external modules will not require any additional permissions.

As for the files update, it will require additional permisions. I agree that it's not good to give them to the whole web app. But isn't there any other solution?

5/29/2007 7:54:29 AM
Total Posts 18439

Re: Custom features for mojoPortal

I do plan to make it possible to drop sql scripts into subfolders for install/upgrading of separate features just like the core of mojoPortal, I just haven't worked all the way through it yet. Right now WebStore is not a released product but I plan to make it so that it can be installed on a server by dropping the files in the correct location including the db scripts. When I release it I will also make a package of precompiled files for production deployment but for now its only in svn because its only ready for developer testing and experimentation, but as I complete it I will also be figuring out about instalation and upgrade and then it will be clearer for other developers how to do the same in their own features.

post build events are only for development machines. I never deploy c# source code on production servers. Keeping your projects in a custom solution seems to work fairly well, you can have different solutions with different groupings of features if you need or keep them all in one. Someone could also implement custom builds and file packaging using Nant or CruiseControl or Sandcastle or something like that.

as for web based installation of dlls I cannot think of a secure way to do that easily. In theory if you could change the identity of the executing thread temporarily to a machine/domain user that has write permission to the bin folder then it might be possible, however this would not be easily usable in hosted environments and could also introduce security vulnerability even if done carefully. So I don't choose to follow that path.

running the db scripts from the upgrade page doesn't require special priveledges other than the user in the db connection string needs permission to modify the schema. But it is not required that the connection string in web.config have a user with this permission, if the user does not then you will be prompted to enter a different connection string for upgrade and if ssl is available you can enter the connection string in the page and it is encrypted when sent to the server. So you could have a user in the main connection string with limited privledges and only enter a dbo connection string at upgrade time right in the page. For example you could create a db user that only has permissions to execute the stored procs in MS SQL and use this user in your main connection string. This user will not be able to do the upgrade so you would be prompted for a connection string.



You must sign in to post in the forums. This thread is closed to new posts.