Hi Dave,

I'm still in the early stages of this project. During the alpha stage, upgrading will be a manual process of comparing the installed db to the new scripts and changing the db to match. Eventually I will have a process for upgrading.

If you create new functionality or modules that you would like to contribute to the project, you can send them to me. As long as I agree they are useful to most users and well implemented and you agree to make it available under the  Common Public License, I will integrate them into mojoportal and list you in the credits.

If you have customizations that you don't want to contribute or for whatever reason I don't think should be included in the core, the best approach would be to compile your stuff into separate assemblies so you can drop the dll(s) into the bin and the markup pages/controls into the appropriate folders of a new version of mojoportal. Eventually I'll have a tutorial and sample code on how to do that. Your pages and controls would inherit from your assemblies so you might have the following:
MyCustomModule.ascx - inherit your own class from a class library project
MyCustomPage1.aspx - (if your module needs supporting pages) you would still want a reference to mojoportal.Web to integrate the skinning but you would inherit your own class from a class library project.
MyNameSpace.Web.dll would be the class library containing the classes for your pages/controls
MyNameSpace.Business.dll would contain business logic for your custom stuff
MyNameSpace.Data.dll would contain your data access code.

If your custom module needs to leverage exisiting functionality in mojoportal, it would be appropriate for your MyNameSpace.Web.dll to reference mojoPortal.Web.dll and for your business layer to reference mojoPortal.Business.dll so you could call their methods.

Definitely if you implement the blog api stuff and it needs to integrate in the existing blog module and you want to contribute it, send me the changed files and I'll integrate it as long as all of it is open source.

Also the latest version of mojoportal source code is now available via anonymous checkout direct from Subversion source control hosted on forge.novell.com. I'll be blogging about that later today. I had to change the VS.NET web project to a class library project to overcome a compatibility problem between subversion and VS.NET web projects, but there is a good tutrial on how to do this without losing any of the conveniences of a web project. More details to follow in my blog. I will say that Subversion blows the doors off SourceSafe in my opinion though I've only used Subversion for a short time and am a long time VSS user.

Hope that helps,

Joe

I haven't had a chance to do the tutorials yet but there are 2 approaches that can work as far as creating your own modules, 1 using external modules that plugin and a second approach that involves compiling your custom modules into the same dlls as mojoportal. The second approach is actually a little easier and goes roughly like this:

1. You get the mojoportal source code directly from svn using anonymous checkout with TortoiseSVN
2. For your custom module you create a user control that inherits from mojoPortal.Web.SiteModuleControl as the entry point to your module and you add it to your web site using the Feature Modules page under Admin. If your module needs additional pages you also create them and link to them from the module control as needed.
3. You build the solution with your additions and deploy.

As long as your module names and page names don't conflict with mojoportal file names, they will never be overwritten by getting the latest version of mojoPortal from svn so it should not be difficult to upgrade from svn and keep in synch with the main features of mojoPortal as they are upgraded, the only thing that will happen is the project file will be overwritten so it won't know that your files are part of the project so you have to use Solution Explorer in VS.NET and right click and add the files back in and rebuild and you should be good to go again in most cases.

Not to say there would never be bumps in that process but as long as you get it working on a development machine before deploying it should be not to bad to get over the bumps.

You know tables will be added and columns etc as features are enhanced or added etc, skins and stylesheets might have features added that would require updates to your customizations etc.

I know thats not very detailed but thats the gist of it and I hope that helps. I really do need to take some time soon and flesh out more documentation.

Joe

You could also start with the second approach then move your code behind into separate class libraries after you are done developing.  Its just easier to do the development using the second approach but once you're done its fairly easy to move to separate dlls.

Hope that helps,

joe