Release 20050319 alpha is now available

See the download page for details.  mojoPortal now supports multiple sites using one installation and db. 
Each site must have a different host name entered in the mp_SiteHosts table, if no matching host name is found the first site in the mp_Sites table is returned.  The sites sharing a single installation each have separate users and content but they do share the same culture.  To support a different culture, you still need a separate installation and db.

As always, if you have any trouble with mojoPortal, please post in the forums and I will try to help as soon as possible.

Next steps in the development plan

Support for PostgreSQL is coming soon thanks to Joseph Hill of GotMono.com!

Page/Menu hierarchy improvements.
Currently, you can't create more than one menu item that points to the same page and you can't create menu items that point outside the page hierarchy either on site or off site.  I am going to change this so you can create "pages" that just point to a link which can be an exisiting page in the site or an external link.  You will also be able to configure whether it opens in the same window or a new one.  Also I will implement a feature so that a page can be configured to automatically display  links to its child pages.  For example, consider the Documentation menu item on this site, it is really just a container menu for other pages with specific documentation.  With the current implementation I had to add an Html Module to that page and manually add links to its child pages.  The next version will have a checkbox in the page configuration to do this automatically.

Moving content modules to different pages is a much needed feature that should be pretty easy to implement.  It can be done now manually by changing the PageID of the module in the database but I will make this very easy to do.

Module Consolidation
Not long ago I added features to the Html Module to allow configuring it for multiple items to support articles and announcements.  Now I see that there is almost a feature overlap with the blog module.  If the Html module had RSS, Comments and Archive capabilities the blog module would not be needed because the Html module could be configured as a blog.  I am planning to create a new Content Module that will combine all these features and will also add a content rating system and the ability to attach a threaded discussion to any content.  At that point I will move the current Blog and Html Modules out of the core and into separate assemblies.  This will provide backward compatibility for users with exisiting installations that are already using the Blog and Html modules and will also provide a reference architecture for others who may want to build external modules that plug in to mojoPortal.

Search
I had been thinking I would use Lucene.NET as the search engine for the site but now I'm leaning back toward using traditional db search capabilities.  My reasoning on this is that pages in mojoPortal can be configured as only visible to users in certain roles. I think the search needs to take into account whether the user is logged in and what roles the user is a member of in order to only display content that the user has rights to view.  I can easily pass the user id as a parameter for searching in the db and limit results to content on pages the user can see.  I haven't figured out a way to do something similar with Lucene but I am open to suggestions if those of you more familiar with Lucene.NET see something I am missing.

Posted by mojoPortal Saturday, March 19, 2005 4:20:00 AM Categories: Releases

Comments

Martijn Boland

re: Release 20050319 alpha is now available

Saturday, March 26, 2005 2:06:51 AM
Related to search and security: you can define any fields you want in DotLucene documents. So in Cuyahoga, I store the ID of the section (module) where the content belongs to in a custom field in the document. Now when a search is performed, all results are retrieved and these results are then filtered by checking the permissions of the current user on the section where the search result belongs to. Works great and there is almost no performance hit since Cuyahoga already caches the entire site structure, including stored permissions. An other alternative could indeed be to store the roles that can view the content together with the document so you can let DotLucene do the filtering. I don't know if these suggestions make a lot of sense for MojoPortal because I'm not very familiar with the code base, but DotLucene is just too powerful to swap it for a tradional db search.
Martijn Boland

re: Release 20050319 alpha is now available

Saturday, March 26, 2005 2:08:36 AM
Wow, I thought I inserted some line breaks but they don't seem to show up. Should we use html here?
Joe Audette

re: Release 20050319 alpha is now available

Saturday, March 26, 2005 2:39:16 AM
Hi Martijn,
Thanks for the info about Lucene.NET. I will definitely look more closely at how you used it in your framework and see if I can do something similar. I really like the way you keep the index up to date in your approach. Your site and code is the only good example of using Lucene for ASP.NET that I could find. I was very glad to find it and also noticed that you mentioned mojoPortal in your site. I've been meaning to write and say hello for some time now.
I am a newby to Lucene and appraciate any advice you can give. The idea about storing the Roles that can view the page with the Document might be a good approach too. When you say "Document" you are talking about a Lucene Document object right? That sounds like it would be the fastest. Is there a way to update it if the roles change in the db? The way mojoPortal currently works view permissions are set at the page level while edit permissions are set at the Module level. For search I think I only need to be concerned with view permissions but I will need to think through how to keep Lucene in synch if the view permissions change after the content was indexed. I guess I could update Lucene at the time when page view roles are updated just like updating when content is added or updated?
As for the line breaks, you are right on that too. I think I will swap out the textbox and use FCKeditor for the comments so it displays more as expected. If you'd like to discuss this more with better formatting please start a thread in the Feature Requests forum. I certainly would appreciate any elaborations or additional recommendations about how to implement it.

Many Thanks,

Joe
Joe Audette

re: Release 20050319 alpha is now available

Saturday, March 26, 2005 3:54:03 AM
There, it should format better now.

Thanks,

Joe
Martijn Boland

re: Release 20050319 alpha is now available

Saturday, March 26, 2005 10:39:28 AM
That's some cute editor here right now :)

To be honest, I completely forgot about keeping the view roles and the roles that are stored in a Lucene document in sync. That is a major issue.  I think you'll need some events here to keep things synchronized. But I'm sure you'll find a way out.
Oh and one thing: DotLucene can't update documents when something changes, you have to delete the existing document and add a new document with the changed properties. It took me quite some time to find out about this...


Comments are closed on this post.