In less than 3 months after the release of the first beta, the Sense/Net 6.0 Beta 2 is available for download.

Sense/Net 6.0 Beta 2 comes with new features like:

• New Portal Explorer based on ExtJS 2.2
• WebDAV support for the Sense/Net content repository (PFS)
• Import & Export form content repository
• Document Library portlet added
• Improvement is other portlets
• Content Store REST service and CMIS service prototype
• A ton of bug fixes and optimizations

Please register at our website for beta test and/or download the latest release.

Happy holidays.

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

We have developed a CMIS draft implementation in Sense/Net 6.0 Beta 2, soon to be released. It is possibly the first .NET implementation, as all supporting companies except from Microsoft are JAVA based. It is surely the first open source implementation on the .Net platform.

What is CMIS? Quoting WikiPedia: “Content Management Interoperability Services (CMIS) is a proposed standard consisting of a set of Web services for sharing information among disparate content repositories that seeks to ensure interoperability for people and applications using multiple content repositories. EMC, IBM, Microsoft, Alfresco, Open Text, SAP and Oracle have joined forces to propose CMIS, the first Web services technical specification for exchanging content with and between Enterprise Content Management (ECM) systems. The proposed standard has been registered for public comment with OASIS. More specifically, Content Management Interoperability Services (CMIS) is a technical specification domain model (data and services) for interacting with an ECM repository via Web Services. It provides a content management domain-specific data model, a set of generic services that act on that data model and several protocol bindings for these services, including: SOAP and Representational State Transfer (REST)/(Atom).”

Since Sense/Net 6.0 is both an Enterprise Portal and an Enterprise Content Management System, with its own Content Repository, we wanted to showcase how easy it is to use the .NET platform, WCF and Sense/Net 6.0 to implement the standard.

Our demo is a two way implementation, because our content repository has a CMIS service interface and our portal has a CMIS client Webpart (portlet). So other CMIS clients can access our contents, but our portal can aggregate content from other CMIS compliant systems, such as next generation SharePoint, Alfresco and others.

We are also building an online CMIS demo, which is accessible from our website, but is under construction, so it might not work all the time. The demo features two CMIS webparts. One is able to navigate the content repository; the other is able to aggregate content from two sources that you can enter. The screenshot above is the CMIS test webpart, showing the PFS root contents. The services can also be accessed, just copy the URI-s from the input boxes. It even works with a simple browser, showing XML. There is no authentication, so no login is required. 

The source code will be available within a few days, please stay tuned. is available for download from http://www.sensenet.hu/download 

Read more about the proposed CMIS standard at OASIS: http://xml.coverpages.org/cmis.html#biro; http://xml.coverpages.org/ni2008-09-10-a.html

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.

It's been a long way. It started with the Sense/Net Portal Engine 1.0 back in 1998. From this construction evolved the 2.0 and upcoming versions all the way up to the Sense/Net Portal Engine 5.5 Release 2 released in 2006. This was a truly enterprise CMS but with the source closed. Two years ago we decided to start from scratch and develop a radically new concept under an open source lincense. And today we've come to the point when all of the Sense/Net team is happy to announce that 

Sense/Net 6.0 Beta 1 has been released!

This is the end of a long road, and the beginning of an even longer one. By opening up the project and the source we want you to use, spread and help the develop a project truly unique.

Join us on this journey 

And harvest the most of SenseNet 6.0.

I have just come across a blog post about Alfresco on CMS Watch. In his post Alan Pelz-Sharpe writes that Alfresco is more developer friendly, especially when you want to push SharePoint beyond its limits. I agree that it is easy to push MOSS to its limits, and also agree that there are certain hardships you have to face when you develop with MOSS. But I still can not see how a JAVA based product could be a real alternative. More...

Our apple of the eye PFS is getting smarter and smarter every day. Beyond its capabilities in storing typed information in an arbitrary object tree or graph, PFS also provides (or under the way to start providing :)  a wealth of tools to create and execute queries at runtime against the datastore. While we have PortalFileSystem.Search namespace at hand with its QueryExpression class, developers using the Microsoft .NET Framework 3.5 will also want to utilize our declarative, strongly typed query API. And by this fall we will have the LinqToPFS provider to support standard query operations with sql like syntax.

(This short writing is by no means wants to be a complete documentation on how to build queries against the PFS. That will come in a later entry - I promise. Now it's more like an apatizer to develop your hunger - or if this would already be the case then a small chunk of meat to keep you from starvation).

In our example query scenario we will search for a User object with a given name under a specified part of our object tree. (As you might already guess in the PFS every single information entity is stored as a Node or a subclass of a Node. This covers folders, files, images, even users - you name it.)

1) Using PortalFileSystem.Search

            NodeQuery query = new NodeQuery();
            ExpressionList expressionList = new ExpressionList(ChainOperator.And);
            expressionList.Add(new TypeExpression(ActiveSchema.NodeTypes["User"], true));
            expressionList.Add(new StringExpression(StringAttribute.Path, StringOperator.StartsWith, "/Root/Intranet/Users"));
            expressionList.Add(new StringExpression(StringAttribute.Name, StringOperator.Equal, "Name"));
            query.Add(expressionList);
            NodeList<Node> result = query.Execute();
            User user = result[0] as User;

2) Using Qry #1

            var qry = Portal.Root.CreateQuery<Node>();
            qry &= node => node is User;
            qry &= node => node.Path.StartsWith("/Root/Intranet/Users");
            qry &= node => node.Name == "Name";
            User u = qry.Execute()[0] as User;

As you can see this form is more concise plus frees you from learning our QueryExpression syntax - for the cost of the .NET 3.5 being a runtime requirement.

3) Using Qry #2

            var qry = Portal.Root.CreateQuery<User>();
            qry &= node => node.Path.StartsWith("/Root/Intranet/Users");
            qry &= node => node.Name == "Name";
            User u = qry.Execute()[0];

4) Using Qry #3

            var UsersFolder = Node.Load("/Root/Intranet/Users");
            var qry = UsersFolder.AllChildren.CreateQuery<User>();
            qry &= node => node.Name == "Name";
            User u = qry.Execute()[0];

5) Using LinqToPFS  - "blue print version"

            var userquery = from u in Portal.Root.Children<User>
                                    where u.Name == "Name" and u.Path.StartWith("/Root/Intranet/Users")
                                    select u;
            User user = userquery.First();

Hi there! This is Mike, the guy who is working on the Oracle data provider of the PFS. But today I'm writing this post in a different role. It's time to use the system, it's time to create my first content type definition (CTD).

One of our clients needed a Reseller search module for his portal. The task is simple: the user selects a Town from a list and gets the Resellers located there. I'm sure there will be lots of posts about such things like creating a GUI with different methods in the future, but now I want to focus on the creation of the Reseller content type and the filtering.

The Reseller content has a few simple properties: name, address, phone, etc. These will be stored as ShortText properties, no suprise. The tricky thing is how to store the Town of the reseller. There are several solutions, depending on the amount of data and the functions the module needs.

1. the simpliest

<?xml version="1.0" encoding="utf-8"?>
<ContentType name="Reseller" handler="SenseNet.PortalEngine.Content.GenericContent" parentType="GenericContent" xmlns="http://schemas.sensenet.hu/PortalEngine/ContentTypeDefinition">
    <Title>Reseller</Title>
    <Description>Reseller content type for a reseller search module</Description>
    <Icon>Reseller</Icon>
    <Fields>
        <Field name="ResellerName" type="ShortText">
            <Title>Name</Title>
            <Description>Name of the reseller</Description>
            <Icon>field.gif</Icon>
            <Configuration></Configuration>
        </Field>
        <Field name="Town" type="ShortText">
            <Title>Town</Title>
            <Description>Name of the town. Please be careful typing it.</Description>
            <Icon>field.gif</Icon>
            <Configuration></Configuration>
        </Field>
        <Field name="Address" type="ShortText">
            <Title>Address</Title>
            <Description>Street, No</Description>
            <Icon>field.gif</Icon>
            <Configuration></Configuration>
        </Field>
        <Field name="Phone" type="ShortText">
            <Title>Phone</Title>
            <Description></Description>
            <Icon>field.gif</Icon>
            <Configuration></Configuration>
        </Field>
    </Fields>
</ContentType>

Of course we can store the Town in a string property. This is a good-enough solution, the town selector dropdown can be populated from it. This works very well, if there are not too many resellers and the administrator of the module doesn't make too many typos...However the filtering from these kind of contents is easy:

NodeQuery query = new NodeQuery();
query.Add(new TypeExpression(ActiveSchema.NodeTypes["Reseller"]));
query.Add(new StringExpression(ActiveSchema.PropertyTypes["Town"], StringOperator.Equal, townName));
return query.Execute();


2. the fool-proof
The problem with the solution above is that somebody will surely type "Assterdam" instead of "Amsterdam" so lets see a better one.

        <Field name="Town" type="Choice">
            <Title>Town</Title>
            <Description>Name of the town</Description>
            <Icon>field.gif</Icon>
            <Configuration>
                <Type>SingleSelect</Type>
                <ExtraField>false</ExtraField>
                <Options>
                    <Option value='0'>Budapest</Option>
                    <Option value='1'>Debrecen</Option>
                    <Option value='2'>Szeged</Option>
                    <Option value='3'>Sopron</Option>
                </Options>
            </Configuration>
        </Field>

Here the administrator will have to choose from a list. When a new office opens in a new town, this list has to be updated in the CTD. This is not a big deal, but there is a solution that builds on the advanced capabilities of PFS.

3. the beautiful
Let's remove the Town property from the content type. This information will be stored in a folder structure in the PFS!

Instead of putting all the Resellers into one folder, lets create a separate folder for every Town. This boosts up the filling speed of the dropdown, because we don't need to iterate through the contents to collect the town names, only need to query for the folders. The reseller search is also faster, because we can use the Path property:

NodeQuery query = new NodeQuery();
query.Add(new TypeExpression(ActiveSchema.NodeTypes["Reseller"]));
query.Add(new StringExpression(StringAttribute.Path, StringOperator.StartsWith, townPath));
return query.Execute();

The good thing is that we can choose either of these solutions, the administration is very easy. I haven't written any content view actually because the generic view is absolutely enough for creating new Reseller contents. After uploading the content type definition, one can go to Portal Explorer and just click the New Reseller link in the Actions menu. The engine builds the form and we can fill the properties we defined in the content type definition above.

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.