One of the main features of the Xmas preview edition of Sense/Net 6.0 Beta 5 is the Content List View framework. A Content List View is basically an ASP.NET User Control that can be used to display Content items in various fashions. We have created the framework to allow for several levels of customization. Deployers and builders have the option to create entirely new User Controls either with a compiled classbehind dll placed in the binary folder of the Sense/Net installation, or using solely declarative components, such as the newly introduced SenseNetDataSouce. However, existing, built-in views can also be altered, and several variants of a single built-in view can be created in the system.

The template engine

The framework of built-in Content List Views is comprised by two levels - a template level and an instance level. The instance level is the actual User Controls that are loaded and executed by the Webforms engine to display the Content List. Every View configured by users on a single List is represented by an instance containing the configuration-, and metadata of the view, and also the actual User Control code that is auto-generated from said metadata. What facilitates this auto-generation is the template level of the infrastructure.

In creating this template engine, we considered several options to use as the templating language. In the end we have decided for XSLT, considering its wide penetration in the web industry, and also its relative simplicity and power. The code that does the actual work in creating the instance View from the template resides in the class Portal.UI.ContentListViews.Handlers.ViewBase. This is the Content Handler for the Content type ContentListView, the type of View instances. Upon the Save event of a ContentListView, the code contained in this class loads the document referred in the Template property as an XSLT template, and executes the transform on the XML document passed on by the virtual method GetSource(). By overriding this method in the Handlers of specific Content List View types - such as list views, calendar views, icon views, etc. -, the metadata necessary to generate the markup for the given view type can be passed to the template. In the ViewBase class, the data passed to the template is an empty XML document.

In the final product, the selection of this template file will be obscured from the user as an internal detail, but currently it needs to be selected by hand upon creating a View instance. The reason for this is flexibility for testing and prototyping, and also the fact that we were in a hurry, and had more important stuff to code.  For you, as a developer checking out the new interesting features of our product, this is most definitely a Good Thing.

Currently there is a single View type implemented in the system, the list view. The list view - not to be confused by the "Content List View" framework, which means the entire big thing - is the "one item per row" view all so know from user interfaces dating back more than twenty years, including those of Norton Commander, Windows Explorer and Microsoft SharePoint Server. The handler class for this View type is Portal.UI.ContentListViews.Handlers.ViewBase.ListView. The XML source used for the transform is the XML formatted list of columns to be displayed in the view.

Editing the template

Now, the User Controls used as the instances for List Views were designed to be user-modifiable. The ClassBehind implementing the logic of the View type contains references to well-known control IDs. Any User Control markup containing the needed controls of the right type with the right IDs will function in this system.

However, the markup of a View instance should - and in fact, can - only be modified through the XSLT template. Any changes to the instance markup itself would be overwritten during Save. To give you a taste of how this works, let's have a look at the built-in template for list views: /Root/System/SystemPlugins/ListView/Templates/ListView.xslt. (This path may change in later releases.)

This is the main template in the XSLT file, describing the outline of the markup. As you can see, we have decided to escape all ASP.NET markup in CDATA blocks. This was necessary to maintain readability and simple editing, as ASP.NET code is non-xml and contains lots of special characters, and so doesn't play nice with XSLT at all. Note how the ClassBehind SenseNet.Portal.UI.ContentListView.ListView is referred in the header, and also note the two known controls: the sn:ListGrid and the sn:SenseNetDataSource. (The ListGrid is a wrapper over the ASP.NET ListView webcontrol, adding JavaScript for visual and behavioral effects. The ClassBehind will accept standard asp:ListView controls without problems.)

To create a new look for your ListView, try creating a copy of this template as MyListview.xslt. At first, try changing the sn:ListGrid to an asp:ListView control without further modifications. Now, take one of the existing List View instances under the demo document library, and modify its Template to MyListView.xslt. Upon saving, the new template will be used to regenerate the markup. On viewing the document library with this View, you will see that the Javascript effects have disappeared.

Further things to play with:

• Add additional HTML markup to the view.
• Try to convert the list view template to use an Unordered List instead of a tabular layout.
• Add an additional, declarative ASP.NET server control to the view.
• Try databinding it to the SenseNetDataSource.

Here is the first working version of the Workspace in Sense/Net 6.0 Beta 4. Code release is planned for next Friday, 24th of July. Stay tuned. 

This is a real screenshot made from a working version, unlike the one created in Corel Draw in my previous post.

We're happy to introduce that an enhanced version of the Sense/Net 6.0 Beta 3, Sense/Net 6.0 Beta 3.1 is out.

Go to http://www.sensenet.hu/download to download. 

Some features in this new release include:

• New portlets: simple Event Calendar, Forum and Video portlet. These components are expected to undergo further development but we decided to include them in this release due to the positive feedback from our clients
• Smoother frontend editing interface: instead of the small icons used to edit Portlets a menu dropdown menu has been implemented.
• Content Picker integrated in the Rich Text editor
• Sense/Net Application Model
• Lots of bugfixes

And of all the improvements the greatest one is probably the Sense/Net Web Platform based Installer! Installing or re-installing Sense/Net 6.0 takes just as long as... about 3 minutes See the video for yoursef - which is also available in various formats on the videos page:

Note: before installing you might want to read the Web Platform Installer guide on prerequisites for the install. Also see the video on installing the Web Deployment tool which has to be installed for the Web Platform Installer to work.

I would like to share the first draft GUI design for a Sense/Net 6.0 Workspace. Workspaces are special containers in the Content Repository, where you can store all data related to a given thing, such as a project or some other team activity. The most common things to store in a Workspace is documents, but memos, calendar events or deadlines, images, announcements and other items are also possible. Each Workspace has a Dashboard, where the activity in the Workspace is easy to follow. This is real Enterprise Content Management in action.

The example below is a Sales workspace, where a sales team store all of its documents, memos, deadlines, announcements and a sales datasheet. The screenshot is about the dashboard, it is easy to see that it has a URL, and some portlets. One of these portlets shows the datasheet, the others show queries of changes, such as the lates memos, or upcoming deadlines.

You can see from our Beta 4 roadmap that the Workspace is our number one priority in the next release. I will post more screenshots of subpages soon.

Note: This is only a GUI plan made in Corel Draw, not a real screesnhot.

I have just received this screenshot showing the working prototype of a Silverlight based Content Type Editor. As you know, Content Type Definitions or CTDs are stored in the Content Repository (SNCR or PFS) as XML. While XML editing is nice and simple for coders, it is a nightmare and minefield for business users. So what we need is an editor that creates a valid CTD XML  with a friendly and foolproof GUI. Since we wanted to try Silverlisght as an ECMS GUI for quite a while, we decided to do this one in Silverlight. This is just a layer built on top of the XML CTD, so business users can use the nice GUI, while coders can use the raw XML. This Content Type Editor will later become a Form and List editor, so business users will be able to create lists, inventories and forms with a few clicks. We are also keen to see how this thing runs with Moonlight, so we stay browser and client OS independent. Enjoy the shot, I think the GUI needs no special explanation - we can see a list of content types and the content type "user" in detail.

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...