I've started to work on the feature to allow site members to send private messages to other site members, but in addition to the typical implementations I've seen for forums that allow this, I've decided to be a bit more ambitious. I really want mojoPortal to evolve to something you can run a business on so I'm envisioning site mail as just the first feature of a more elaborate SiteOffice feature.

All registered users will be able to use the SiteMail element of SiteOffice to send messages to other site members but in addition to that I will have roles that allow users to also access external email accounts, send and recieve mail from those accounts, maintain personal contacts separate from site member contacts etc.
Later I plan to add a role to alow users to store files, eventually we will hopefully see open source editors for OpenDocument format and ultimately the whole office experience can be had in the browser. You can see how this could progress with nice calendaring for users and groups and other typical office like features.

So far I've just stubbed out some UI using jsObjects TaskBar and TreeView with some MagicAjax Panels. Registered users who login can get a sneek peek at the UI using this link http://www.mojoportal.com/SiteOffice/Default.aspx and I invite your feedback whether you think this is a good direction to go. Its pretty similar to older versions of Outlook. I've experimented some trying to make a UI more like newer versions of Outlook using the Rico Accordian panel and some of the dojo layout widgets. dojo has an accordian but it seems broken in IE. The idea would be to have the treeview inside the accordian panel which would be more similar to the newer versions of Outlook and you can see my experiment here http://www.mojoportal.com/SiteOffice/Office.aspx. I'm just not sure yet if I can get a hook in to handle client side clicks to the accordian that I need to show and hide things like I am using the dsObjects stuff. I got a good chunk of work done already using jsObjects so not sure if its worth the effort to pursue the accordian thing and this is what I'm asking feedback about. I'm at apoint where I see clearly how to implement things with jsObjects whereas the other stuff is going to require more digging and experimenting. I'm kind of leaning toward sticking with the jsObjects approach and maybe trying to integrate the dojo feature that allows re-sizing the layout elements. The only problem so far I've had with the jsObjects is in Firefox the height of the taskbar seems to want to go a little longer than the page height no matter what I try though their sample page doesn't have this problem. I'm thinking it might be all the hidden Ajax panels are somehow taking up space in Firefox even when they are hidden.

Some of the things I plan to use for the external email functionality are DotNetOpenMail, sharpmimetools, and the mono.net.POP3 classes. I also found sharpwebmail which has the POP3 functionality but I can't use it because it is licensed under the GPL. Luckily I remembered reading Zac Bowling's blog that he had contribute some POP3 feauteres to the Mono project and I can use that.

Nothing is functional yet but you can see by clicking some of the buttons how the Ajax partial postback is nicer than normal postback.

So login, have a peek and let me know your opinion.

Thanks,

Joe

I just updated this site to the latest 2.1.1 from svn for final testing before the release this weekend.

This release will include the new localization model which detects the browser language and uses resource for that language if available. So anyone visiting this site using one of the languages we currently have translations for should see the labels and buttons in their own language.

Currently mojoPortal is tranlated into:
English
Spanish-Mex
German
Dutch
Turkish
Russian
Czech
Italian
Portuguese (Brazil)

So if you set your browser language to one of those you should see the labels and buttons change to those languages on this site.

Also this release features a new help system making it easy to add contextual help links anywhere in a page or module with an editing system to make it easy to update or translate the help files.

The Image Gallery also uses a new modal dialog to show images. I've added an image gallery to the MyPage page, click one of the thumbnails there to see how cool the new modal dialog is. The same dialog is also used in the help system.

This will be an easy upgrade as there are no changes to db tables. Users of MS SQL and PostgreSQL will need to run the stored procedure scripts to get the latest procedures.

Access/shortcut keys for all important buttons is another new feature this release. It can be disabled from the web.config file if you don't like it but its pretty convenient not having to grab the mouse for everything.

This release will also be able to run in Medium trust hosting environments.

If you've visited this site before you've probably noticed the new menu icons. Just added that over the weekend into branches/2.1. It was low hanging fruit. There was already a field in the mp_Pages table for MenuImage that had been there a long time but not implemented as a feature. So I added the UI elements to pick an icon and hooked it into the menu.

The only interesting bits about the implementation was that while the ASP.NET Menu items have an image property, the standard SiteMapNode does not so there was no where to store it when populating the node tree from within a custom SiteMapProvider. Not a difficult problem at all though, I just implemented a mojoSiteMapNode that inherits from SiteMapNode and add a property to store the image url. Then when I build the node tree I populate it with mojoSiteMapNode objects.
Since I'm already handling the MenuItemDataBound event to filter the menu based on roles I just had to add a little code ther to populate the image like this:

mojoSiteMapNode mapNode = (mojoSiteMapNode)e.Item.DataItem;
if (mapNode.MenuImage.Length > 0)
{
      e.Item.ImageUrl = mapNode.MenuImage;
}

Pretty sweet!

The other cool thing that landed in svn branches/2.1 this weekend was my further WebPart work including the WebPartModule and WebPartAdminModule features mentioned in my previous post, allowing use of 3rd party WebParts (if you can find some) both in the MyPage feature and anywhere in the content system. Also I have implemented the feature on MyPage to allow users to create as many "pages" of personailzed content as they like similar to pageflakes.com.

Now I still have some work to do in styling the User Page Menu on MyPage in the various skins (so far I've only been working in subblue). I'm not the greatest designer as I'm sure you have observed but hopefuly it will come out looking something like tabs.

With this, almost all of the compelling new 2.0 ASP.NET features are being used to good advantage in mojoPortal which means we are getting close to a time when I can try and focus on identifying what needs work in mono to get mojoportal 2.x working. There is still just one more big 2.0 feature I would like to take advantage of and that is the new improved localization features. I shied away from the conventional 1.1 .NET localization in the current mojoPortal localization implementation because I felt it had one fatal flaw. It required storing resource strings in satellite assemblies which meant a developer would need to be involved just to change a label. I felt very strongly that it should be possible to change any label with a text editor and not require any compilation. This and more is now possible and efficient in 2.0 .NET and would give us some ability to adapt labels in the site to the culture of the user's browser (if we have resources for his culture) with fallback to a default culture if not available. I still think the value added is very limited because the bulk of the content comes from the db and will never localize unless a person translates it but it is worth doing because there is some benefit if the login button and other buttons are localized as well as calendar and date time formats, it may help someone who knows some english for example but is not fluent.

I think I am leaning toward making the 2.1 release before tackling the localization changes. It will not be difficult but it will be a lot of grunt work copying strings from the culture files into the resource editor and going through the site to make the changes.

So I guess its a little more polish on the MyPage stuff, some QA and then make the 2.1 release

For those of you following along with the sources from svn, I pretty much work in branches/2.1 most of the time except when making changes that require db schema changes. To avoid breaking things for users who are working from svn I do the db change work in my sandbox branch and only merge it back into 2.1 once I have all the data layers implemented. This weekend I merged quite a bit, you may need to look for the newer stuff in the upgrade scripts if you are working with an existing db. There is still quite a bit of things to do before the release but I think the db changes are done for this coming release.

I implemented the WebPartModule and WebPartAdmin module in my sandbox over the weekend using the MS SQL data layer. I still have some work in the other data layers but I'm waiting until I complete all the schema changes In this db before moving through the other layers.

These modules work just as I planned using a test dll I made with a simple web part. I was able to drop it in the bin folder, it showed up on a list in the WebPart Admin module as a WebPart available to install. Installing was 2 clicks and 2 check boxes to indicate whether it should be made available for MyPage and the Content System. I checked them both and then was able to use the WebPart on MyPage and in the content system. Pretty Sweet!....but, if you build it wil they come?

Googling I could not find any webpart libraries available for download except those for Sharepoint which are not compatible with ASP.NET WebParts. Often, people don't realize these are not the same thing because they are both named WebParts, but they are not the same thing.

So the utility of this feature is good for developing your own WebParts as features for mojoPortal or other projects using WebParts but we have yet to see much of anything out there right now as far as 3rd party WebParts. Maybe that will emerge later, we shall see.

But anyway, there is still more that I want to do in the MyPage implementation of WebParts.

Similar to what they have over at www.pageflakes.com, I want the user to be able to have multiple pages on MyPage, with the ability to create more as needed.

Also, I want to do something more elaborate with the WebPart Catalog. You can only show so many choices in the default presentation without it getting obnoxious so I need to figure out how to implement it so that the most popular ones show up in a short list and there is a more link where you can open a screen that lets you page through them so that it is not too cumbersome having a large catalog and browsing through them.

I think after those 2 things are implemented I will start the QA process towards a release. Not sure how long that will take, hopefully it will go quickly.

Now that I've had a chance to think more about WebParts and play with the first iteration of WebParts in mojoPortal as implemented in the MyPage feature I'm starting to get a vision for the next steps and here is what I've come up with and will be working on this weekend. Basically, I'm envisioning 2 new modules WebPartModule and WebPartAdminModule.

WebPartModule will allow us to use any installed WebPart as content anywhere in the site. When I say installed I'm talking about assemblies dropped in the bin folder, in other words third party WebParts or WebParts developed as pure WebParts outside of mojoportal and compiled into a class library like MyCustomWebParts.dll and placed in the bin folder beneath the web. Of course WebParts used this way won't have the drag and drop and personalization but will be just like any other content in the site (not including MyPage) and will stay where the Admin puts it. So this module will just be a way to make any WebPart available for the Content System. When installed WebParts are used on MyPage they will have all the WebPart features but the WebPartModule is not part of that equation, its job is just to load a WebPart as if it were any other site content wherever you tell it to. In this context the WebPart will be treated like an ordinary Control.

WebPartAdminModule will allow the admin to "install" the WebParts by entering the Assembly Name, the Class Name, and Description to display in the WebPart Catalog on MyPage. It will also allow configuring whether each installed WebPart is available for MyPage and/or available for the Content System using the above WebPartModule. To make it friendly I may use Reflection to iterate through the assemblies in the bin folder and make a list of WebParts in those assemblies that aren't yet installed. I've already done preliminary work on loading WebParts dynamically from assemblies. The WebPartAdmin module will just give them permission to be used on a site by site basis. In a multi site installation the root site will be able to determine which WebParts are installed in each subordinate site just as we currently do with the Installed Feature Administration in Site Settings. This feature will show the currently installed WebParts and the WebParts found in the bin assemblies that are not installed to make it easy to install them.

So these features will allow us to use third party WebParts on MyPage where they will have all the WebPart bells and whistles or anywhere else in the site where they will be treated like ordinary controls.

I think this will work, should be fun.