The original Portal Explorer has been the administrative interface for Sense/Net 6.0 since the beginning of development - that means almost a year and half. It was well constructed but not really lightweight - neither on client side nor on server side.

We decided that it was time to radically change the workings of it and with the lead of Attila we are proud to introduce a faster and better administrative interface - Portal Explorer 2.0.

The first and most important difference that you will notice that Portal Explorer 2.0 is much faster than its ancestor when it comes to refreshing panels. This is mainly because it uses services to communicate with the server and uses client side controls instead of server side ones. We've migrated from the Ext JS 1.1 JavaScript framework to Ext JS 2.2 which also gave a performance boost. 

What you will probably admire at least as much - if not more - is new functionality added: multiple contents can be selected at once in the list pane, quick search in the grid have been introduced and some minor features tweaked to make everyday work more efficient in Portal Explorer. More...

Our team lead developer is a real geek, and we love him for this. He wrote a Microsoft Power Shell plugin that enables users, especially developers and command line addict sysops to access the Portal File System (PFS) from a command line interface.

As you can see from the screesnhot, the first commands install the plugin, so when you type CD TNG: you actually switch the current directory to the PFS root. A simple DIR command lists the folders from the PFS, indicating the content type, YourInternet is not a Folder, but a Site.

And now for something completely different. The crazy stuff comes now. You change to YourDocuments. DIR gives you nothing, as the folder is empty. But there is the NEW-ITEM command, which creates ECMS contents right from the command line. So why not create some cars, by which I mean Car content types. Another DIR and the cars are listed... But you can also list any of their Fields, in the next example the complex DIR gives you the make and Model fields of the cars.

Another example, when you read a reference property of a content. In this example, we navigated to the IMS folder where users and groups are store, and listed the Members of the Administrator group.

Plans for future functionality include mounting multiple PFS instances and copying contents from one to another, using the copy command. Stay tuned, you geeks.

Nice job, Gyebi.

Yeeeesssss. Portal builders, developers and end users will all love this feature. Now you can access your contents from Total Commander, Windows Explorer or Visual Studio, or anything that supports the WebDAV protocol. You can even map it as a drive. So you can hav P:\ as the root folder of your Portal File System. Check out the screenshot with the first working prototype.

This is a big boost to productivity for both builders and end users, because now you can work from your favourite tools, no need to open Portal Explorer most of the time. When you save a content, it is automatically versioned, there is permission check, etc. You can also open office documents, Word and Excel directly from Office and save it back, so there is no need to download, change and upload files one by one. Drag and drop move and copy also works.

On the screesnhot, there is a Content View open in Visual Studio, there is a Content Type Definition open in IE as XML, and you can see the PFS folders in Windows Explorer and Total Commander, in the latter the PFS root is mapped to Z:\ so the folder is Z:\System\Schema\ContentTypes\GenericContent.

Screenshot made with Windows Vista and Sense/Net 6.0 Beta 2 prerelease.

We have just covered the two new browsers, and a few days have passed. Now we have yet another one around, tossing its name in the goblet. So I decided to summarize the three tests in one post.

The test for all three browsers was the same. It is a really quick end user test to see if our app fails at basic operations, such as browsing the content repository or editing portlets. The app we used for testing is the AJAX based GUI of our open source Portal & ECMS.

In our test we used the following versions:

• Internet Explorer 8 beta 2 (exact version 8.0.6001.18241)
• Mozilla 3.1 (codename Minefield, exact version 3.1a2pre)
• Google Chrome (the very first version that could be downloaded: 0.2.149.27)

The app we used for testing has been optimized to be compatible, and runs pretty well on IE7, Mozilla 3.0 and Safari, both on Windows and on a Mac.

Here is the summary of the test, which included ten functions you can not miss to use the software. The test was conducted in order of appearance.

The Rich Text Editor works with modified version of TinyMCE. http://tinymce.moxiecode.com
Portal Explorer works with ExtJS. http://extjs.com

In Mozilla 3.1 we experienced no difference. Compared to previous versions, it felt a little bit faster and worked fine. It was not surprisingly fast, except for the Rich Text Editor. Turning Tracemonkey, the Javascript JIT compiler did not significantly affect the user experience.

In the IE8 beta, it was buggy. PRC drag and drop did not work, and the Portal Explorer flashed randomly, freezing after a few clicks. Only F5 helped. The rich text editor was totally unusable.

Google Chrome did really well, except for the Webpart drag and drop, without which you can live for a while. It actually worked for one guy, but did not work for me.

So the Winner of the Triwizard Tournament for Browsers is Firefox, but Google Chrome’s very first public release did extremely well, too. For IE8, we recommend another year in Hogwarts.

Wow. I just covered IE8 beta and Firefox 3.1 Minefield on friday, and yet another new browser, Google Chrome comes in my way. I don't want to be evil, but how many will be too much? Normally, competition is good for business, and so should it be for the browser world. More...

I have read posts about both the new Mozilla browser and Internet Explorer 8. Peter and I decided to run a quick lab test to see how fast and compatible are the new browsers.

It was obvious to use Sense/Net Portal Engine TNG for the test, since we are about to release it on the 30th of September, and it has lots of AJAX based GUI-s. This was just a really quick smoke test to see if our apps fail at basic operations such as browsing the content repository, or editing portlets.

In our test we used Internet Explorer 8 beta 2 (exact version 8.0.6001.18241) and Mozilla 3.1 (codename Minefield, exact version 3.1a2pre). More...

We have started preparing for the First Release. In the installation packed, we needed a Default Skin, a skin which will be used to build the pages in the default installation. We have abandoned the idea of using a Beer manufacturing company for the demo portal, as we respect cultures where alcohol is not welcome. so we decided to use the design of our own intranet, which is totally politically correct. This is the screenshot of our current intranet, similar to our website.

The HTML used to build the site is Valid XHTML 1.0 Strict. There is a slight difference in the HTML of our site and the HTML produced by the Sense/Net Portal Engine TNG portlets, because we wanted to give designers greater flexibility in changing the design with CSS only. If we use a very simple HTML, some designs can only be implemeted, if the designers make changes to the HTML itself. If we create a slightly more detailed HTML, adding some extra DIV-s, designers will be able to implement portlas without the need to change the HTML.

In the previous version of Sense/Net Portal Engine, HTML had to be produced by an XSLT stylesheet, which was cumbersome and sometimes ugly to work with. In TNG, we produce HTML which is built in such a way, that it covers almost all design scenarios, except for the most complicated. This way, about 90% of portals will not need to change the HTML, so 90% of designers will not have to use XSLT, which is good news, you know, time is money. And who wants to author XSLT-s anyway.

To implemet your own design, you take the Default Skin's CSS, and make changes to it. The HTML is so nice, it works pretty well in WYSIWYG HTML editors, such as seen on the screenshot below. You can also get a sneek preview of the source here.

Note, that the font in the blue caption of the portlet is not the same as in our website. This is because in the website, we use a technique called sIFR (Scalable Inman Flash Replacement) to change the text into a little piece of flash, which displays the same text, but withour brand font, Frutiger.

This is the first in a series of posts on building custom portlets for the Sense/Net Portal Engine TNG. The good news is: it is as simple as it can be and all you have to do is to subclass from the SenseNet.PortalEngine.Portlet class, implement your custom portlet logic with C# code and then place yours assembly in the portal application assembly discovery path (for example the Bin folder). That's it. As for the bad news there is no bad news here as the Portal Engine TNG Portlet API is basically the ASP.NET WebPart framework, extended with some Portal Engine TNG specific services and tools to simplify development, deployment and maintainance of WebPart based applications.

In these documents it is assumed that you are new to both the WebPart and the Portal Engine TNG technology but you bear with at least a minimal understanding of the ASP.NET Custom Control concept.

So here are the steps for creating a portlet that can be placed on a portal page and will say "Hello World" to me.

More...

Most open source CMS systems only deal with Web Content, while Sense/Net Portal Engine TNG is an Enterprise Content Management platform. But on the other hand, most ECM software do not deal with Web Content at all, or to a limited extent. We have experience with the WCM features of MOSS, and they aren't the best.

For years, our customers demanded total WYSIWYG web based content editor. When designing TNG, we had two equally important goals concerning the CMS system.

• To create a truly scalable and robust, but at the same time open source Enterprise Content Management System
• To make this ECMS capable of handling Web Content in an extremely friendly way

What you see (and soon will get) is a screenshot from out test system, where the Portal Remote Control is visible, and the page is in WCMS edit mode, so all the tools for WYSIWYG content editing are open. In the bottom-left corner, the Content Properties window is open, where you can edit the non-visible fields of the content. The small window in the bottom is the Actions windows, with buttons to Save or Publish your changes. The one on the right side, with the green caption is the Rich Text Editor toolbox, which appears only when the cursor is in a Rich Text field. This one will also be black and transparent, I just did not have the patience to wait with this post, until it is finished. All windows are draggable, so you can place them out of your way when editing. The content appears right where it should be within the page, and the controls do not change the layout of the page, as they float over the page.

We need some usability testing and lots of debugging, but this thing seems to work. Transparency, especially in IE is a little bit of a pain in the neck, because it is too slow, so we are thinking to ship an alternative CSS as well. Just like in the Windows OS, animated menus look cool, but its better to switch them off after a while. We will need to optimize how windows appear and disappear, so they are not confusing users.

Note, that the look and feel of the PRC and the WCMS editor can be customized, since all parts (such as the CSS and images) are stored in the PFS, under /system/pfs folder, just like this:

I will post more shots, when the testing is over.

Like other portal engines TNG integrates a versioning system. The basic versioning modes are None versioning for unimportant content, Major Only versioning (1.0, 2.0, etc.) for regular changing important content and Major and Minor versioning (1.0, 1.1, 1.2, ....1.6, 2.0, 2.1, etc) for content that is created by a team.

Besides this Sense/Net introduces the publishing with approval. Whether it concerns content with or without versioning, we can limit publishing by inducting approval. Actually a content element version in the Portal File Structure (PFS) can have several states, which internally are marked: P for last valid (“Published”), L for Locked, D for Draft, A for waiting for Approval and R for Reject.

If approval is required for certain content, after creation or modification the system creates a version waiting for approval. This is only visible for the user who has the permissions to approve it or reject it. When the content is accepted by clicking the Approve button, it gets the next version number with the character P and it is visual for other users.

In a later version we implement a workflow solution which can use those states seamlessly and which takes for the delivery through the system.

When your content is an important part of your business, this solution is an extra guarantee for reliable and error free storage and publishing.