Merging customizations with framework updates

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.
8/13/2008 11:02:22 AM
Gravatar
Total Posts 45

Merging customizations with framework updates

I was wondering how others who've made their own custom changes to MojoPortal have been handling the merge process with all the frequent updates to the framework.

8/13/2008 11:17:24 AM
Gravatar
Total Posts 18439

Re: Merging customizations with framework updates

You should not make custom changes anywhere except in your own custom projects. Then you can always do svn update to get the latest code. This is no different than what I do when I work on customer features. All the custom stuff is in external projects.

If you think something needs to be changed in the core to meet your needs you can propose it and maybe we will agree or we may give advice how to achieve the result without touching the core.

Best,

Joe

8/13/2008 11:44:47 AM
Gravatar
Total Posts 45

Re: Merging customizations with framework updates

If by "core" you mean all the class library projects like mojoPortal.Business, mojoPortal.Net, and such, I don't intend to make any changes to those. However, there are some aspx or ascx files and their associated code-behinds in the main web project that I would like to tweak since the changes can't really be made through the skins.

8/13/2008 11:52:42 AM
Gravatar
Total Posts 18439

Re: Merging customizations with framework updates

Again, I would recommend you don't do that. If you give specific examples if what you are trying to do I can try to recommend a way of doing it externally.

Best,

Joe

8/13/2008 12:50:26 PM
Gravatar
Total Posts 45

Re: Merging customizations with framework updates

I'll try to explain what we're trying to do. One of the main limitations of mojoPortal is that it seems specifically geared toward the management of web communities where you have users that login, can view content based on their security "roles", can manage their own profile, etc. Obviously, these features are required for authenticated users that are in charge of editing content.

However, if you are trying to building a public portal that allows anonymous, unauthenticated visitors to view the content, then some of the existing features don't work well in this paradigm. For example, the SharedFiles module has a column that displays the user name of the person that uploaded the file. When being viewed by anonymous site visitors, that column is unnecessary. Anonymous visitors to the site don't need to know what internal user was reponsible for uploading the file. On the other hand, if you have a team of internal users managing the content, they do need to see what user uploaded the file. So this particular module needs better customizability to support two different rendering modes--one for content editing and one for content viewing.

Our workaround for this limitation is to have two different mojoPortal installations pointing to the same database. One installation is a private site for content publishing/editing and the other is a public site for content viewing. The private installation uses mojoPortal framework as-is. The public installation has a customized version of SharedFiles.ascx that hides the UserName column on the file list grid. Although this solves our problem of needing two different rendering modes, it does require that we push the changes in the Sites folder from the internal installation to the public installation whenever changes are made to the content. IIRC, AxCMS works this way out of the box. It supports two entry points into the system--one for editing/publishing and one for viewing.

8/13/2008 1:09:55 PM
Gravatar
Total Posts 18439

Re: Merging customizations with framework updates

Hi,

In this case you could suggest that we incorporate your changes. It would be easy to add a module setting to the shared files feature to show or hide columns and or add logic to show or hide if the user is admin or is authenticated.

In this case if you had needs that could not be incorporated back into the project one strategy is to clone the feature and fork it. Basically copy it into your own external projects, change the namesspaces, script off the tables and procedures and do a find and replace to change your table prefixes for your clone to something other than mp_, then do the same replacement of mp_ in your cloned data access code. Give your feature a new guid for the feature definition or moduledefinition so its not the same as the cloned one. I would only choose this strategy if you need customizations that couldn't or shouldn't be incorporated back into the project. Once you have forked the clone you won't get new enhancements unless you add them yourself or port them from updates to our version of the feature as we improve it over time, so ideally its better if we can make ours relatively configurable to meet your needs so you don't have to maintain a fork. But better to fork it than to constantly face merge problems.

Best,

Joe

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