I'm planning soon to implement wrapper aound the WYSIWYG editor in mojoPortal using the provider model pattern so that different WYSIWYG html editors can be plugged in. In the early days of mojoPortal I decided not to do this because at the time there was really only 1 good open source editor and that is FCKeditor which we currently use. There were other things like FreeTextBox but it held no interest for me because its free only in dll form and is not open source.

Recently I have noticed that the TinyMCE editor has really matured and since it is open source I now have a motivation to implement the provider model to make it possible to use this editor in addition to or instead of FCKeditor.

The big advantage I see right away is that it supports Safari and Opera which FCKeditor does not. I also have read some things indicating it has advantages in terms of accessibility as well. I still have not figured out if there is a way to tab out of the FCKeditor with the keyboard, it always requires the mouse because the tab key just tabs within the editor. Maybe I'm missing something if anyone knows how to do this with any key combination let me know.

So I'm thinking it will be good to be able to specify a default editor for the site but if the browser is Opera or  Safari always use TinyMCE. Not sure how long it will take me to implement this but I'm going to look into it this weekend.

I suppose once the provider model is in place it will be possible for using other commercially available editors as well if anyone wants to implement the provider for it.

Those of you who subscribe to svn commit notifications have probably noticed a lot of changes being committed to svn recently in the skins for mojoPortal. I've been doing a lot of work to improve the markup semantics and accessibility and to better organize the css files.

Some of you may be scratching your head and wondering what are markup semantics so I'll explain a little. Historically most web developers and designers have just done whatever it takes to make a web page look a certain way in the browser, we haven't really considered what should the html itself look like very much. The w3c standards and recommendations have been evolving all the while in the background and they have quite a bit to say about how html documents should be structured.

It starts with simple things like the most important heading on the page should use an h1 element and other things on the page should use h2 then h3 and so on for headings in order of importance and containment. Raise your hand if you've ever put a title in an h1 tag then changed it to an h4 or h5 because it was too big. Hasn't everyone done that at some time or another or perhaps we just don't use any h elements at all we just use css to assign a large font that looks like a heading in the browser. By making the most important heading on the page h1 and the next level down h2 and so on we are adding meaning to the markup without regard to its presentation and that meaning will be there even if there is no css. It gives meaning that is helpful for search indexes, screen readers and other devices or web clients so that they can better understand your content. If the default font size for h1 looks too big that can easily be changed with css. The idea is the html should convey a lot of information about the structure of your content and presentation can be handled by css.

Another important example is with lists, I know plenty of times in the past I've made lists of links by just using a br after each link in the list. It looked the way I wanted it to in the browser but it doesn't convey the idea that this is a list. Its much more meaningful to use a ul with li elements to convey a list but when we tried that it indented and put bullets we didn't like so we went back to the br approach. The smart way is to use the ul and li but style it the way we want with css. If we don't like the bullet we use list-style:none;. If we don't like the indent we can use a margins or padding negative amounts if needed. Now the search indexes know this is a list and it still looks the way we wanted.

A good book for those who would like to learn more:

Another important thing is to reduce as much unsemantic markup as possible. That is avoid extra divs and spans as much as possible. Sometimes you really need them to achieve a visual design goal but keep it to a minimum is a worthy goal both in terms of semantics and in terms of performance.  Less markup means faster page loads. The book above and some others have shown me that often when I thought I needed a div to style it was possible to achieve the same result without it, css is very powerful. There is a lot more to it so I recommend the above book as a starting point to learn more but these are some of the core goals and benefits.

I mention this because I've done a lot of work in mojoPortal recently to improve the semantics of the markup including better use of headins and lists. I've also gone through each of the included skins and painstakingly split the css into separate files:

• style.css which ties the others together
• stylelayout.css which has css rules for position, margins, padding, etc
• stylecolors.css
• styleborders.css
• styleimages.css
• styletext.css

These changes are in svn and will be in the next release which should be pretty soon. It was a lot of tedious work cutting and pasting the css to organize it this way in all the skins included with mojoPortal but I think it makes it easier to manage and to understand.

I mentioned in this previous post that I'm working on a new variation of the Multi Sites hosting feature. This work is being sponsored as open source development by one of my customers. I'm not sure if I can mention who the customer is so for now I will leave them nameless.

For a long time it has been possible to host multiple sites using a single installation of mojoPortal with the secondary sites defined by different host names. The new feature provides an option to define the secondary sites by the first folder after the host name like http://somehostname/somefoldername.

The initial implementation of this has landed in svn/branches2.x for anyone interested in trying it out or providing testing. I'm sure there are still a few bugs here and there and am working to test all the features and fix any outstanding issues before making an official release.

I've also updated the documentation here:
http://www.mojoportal.com/muliplesites.aspx
and here:
http://www.mojoportal.com/multiplesitesbasedonfoldernames.aspx
with information about using this feature.

I got an email the other day from Stephen Jazdzewski, a mojoPortal user running his site on Mono. 

He attended the Mix07 conference and mentioned mojoPortal in the QA session at the end of the Panel Discussion: Open Source Applications Using the .NET Platform.

The presentation is now online here. You can hear mojoPortal mentioned at about the 50:09 time reference.

Thanks a lot Stephen!, its great to get a little exposure at such an important event.

Some interesting changes have been committed to svn branches/2.x

One big change is that I have created dedicated physical pages for the admin features (SiteSettings, Role Manager, Content Manager, etc) which until now have just been modules that plug into the content sysem the same as the content modules. Now there is an Admin Menu page with links to all the admin features, and they no longer appear in the main menu. I did this for a number of reasons.

I'm planning to make it configurable which features are "installed" but the admin features should always be there. In the previous model because the admin features just exist on pages in the content system, it is possible to remove the admin features from the site using the content management features with no way to get them back easily without doing it directly in the db.  So separating the admin features into physical pages outside the content system seemed the way to go. This change also helps with multi site installations using one web and db because when new sites are created we don't need to create admin pages in the content system in the new site either.

There are now 2 new skins named treeview1 and treeview2 which are really coopies of the existing jwv1 and jwh1 skins but modified to use the TreeView control for the menu. One of the cool things about the TreeView is its ability to load nodes on demand from the SiteMap. In large sites with lots of pages and deep hierarchies this can be a performance benefit.

When using the normal Menu all the navigation links for the entire site are rendered as markup into the page, typically showing only the top level and using mouse over to reveal deeper nodes. If you view the source you see the Menu rendered as ul and li elements in the markup and every link is there for the whole navigation tree which can be a lot of markup in a large site. The more markup there is the bigger the page size and the slower the perfomance. Since the menu is on pretty much every page its part of the payload of most requests.

The TreeView control also renders as ul and li elements but with PopulateOnDemand it will not render the markup for invisible nodes. When you click a node it will expand and add just the nodes requested. You can see this when you view the source of the page. If you want to check it out, the treeview1 skin has the TreeView for the menu and the treeview2 skin has a regular horizontal menu for the main menu and a TreeView for sub pages beneath the top level. To see for yourself, create some deep hierarchies of pages and view the source of the page as you drill down from the top.

I also shortened the 3 column names on the mp_Users table and 2 column names on the mp_Sites table. Recently there has been some renewed activity by the Firebird data layer team. Firebird doesn't allow columns longer than 31 characters so this was a barrier in implementing the 2.x mojoPortal data layer. By renaming the columns this barrier is now removed so hopefully work will proceed for the Firebird data layer. Thanks to Gareth for all his hard work implementing Firebird for 1.x mojoPortal!

Some have noticed that the SQLite data layer for 2.x mojoPortal was broken a few versions ago and has not been shipped with the last few versions. Joseph Hill, who initially implemented the SQLite data layer has agreed to look into, so hopefully that data layer will come back to life sometime soon.