Hi,

There is a lot of nuance to this question so its taken me a while to answer it. First let me address the main question. It sounds like you would like to have more than one user making blog posts in the same blog and having it show who the user was at each post. I will look into making this possible in the blog as soon as I get a chance.

In general, I do not want to encourage people to just start hacking away at the mojoPortal code to make customizations. Doing so can make it impossible for you to get upgrades without losing your customization. I just wrote a new article Cloning an Existing Feature, to address this. By first cloning a feature, you can then safely make customizations to your cloned copy without losing the ability to get upgrades.

So this connects with your question about API documentation. At one level publishing an API document might encourage people to code against the API when really there is very limited API that I really think should be coded against. There are definitely useful things to be familiar with like SiteSettings, SiteUser, SiteUtils, WebUser.IsInRole(s), but there are a lot of things like individual features such as the blog that I don't recommend coding against.

In general my suggestion is to read the code, it is the best documentation and you can find example code for doing just about anything you might need.

With that said, its not like I'm opposed to producing an API document. The back story on that is that once upon a time I started working with NDoc to automatically generate API documentation. But we have not done a great job with the xml comments to produce a very nice result. I've inappropriately used the <summary section to put license information and a lot of this kind of thing would need to be cleaned up to get nice results and more explantory summaries would be helpful. So just when I started looking into it is when it was time to go to VS 2005 and for a while there wasn't a version of NDoc for it, then finally one was available but soon after it was time to go to VS 2008 and now there is no NDoc for VS 2008. I did recently find that Sandcastle is the new thing for this and the Sandcastle Help file builder. So I have actually generated an MSDN style API document in the form of a .chm file. but again the output leaves much to be desired because we have not made the best use of the xml commenting. It will be a gradual process of fixing the summaries on the most important classes/methods first to get to a really nice output generated from the code and xml comments. For the moment and probably even after we do have a decent API document, I still think the code is the documentation of first resort.

Best,

Joe

Hi Jamie,

This thread is from 2 years ago. Currently we have a link to the API documentation from the developer docs, and it is also downloadable as a standalone .chm help file from the Codeplex download page.

The API documentation is produced by a tool (SandCastle help file builder) so it documents pretty much all the code, it is a tougher nut to crack to try and clarify things one should or should not code against but the main guidelines I would suggest are:

• The main thing is not to modify existing mojoPortal code but keep all customization in your own projects
• Controls in the mojoPortal.We.UI and mojoPortal.Web.Controls namespaces are generally usable in custom projects
• Helper methods in mojoPortal.Web, mojoPortal.Web.Framework, and mojoPortal.Business.WebHelpers can generally be used
• since features should be self contained, custom features generally should not leverage classes in the mojoPortal.Features namespace nor against WebStore or other features, like you should not generally code against the blog classes or forums and such though in some rare cases there can be exceptions to the rule. Like for example if someone wanted to make a custom RSS feed that showed blog posts by category one could potentially get way with that but later when the blog category system is replaced it would break such a feature.
• generally one should avoid coding directly against the mojoPortal.Data namespace from Web code

So I would say poke around the API docs for things that might be useful and/or study how things are done in existing features. Then if you have any specific questions about whether you should or should not code against something I will be happy to offer an opinion.

Best,

Joe