Sense/Net 6.0 Devblog
The development blog of Sense/Net 6.0
Back to Sense/Net

Sense/Net adopts the CMIS standard - the first in .NET world

November 3, 2008 19:16 by Tamás Bíró

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#birohttp://xml.coverpages.org/ni2008-09-10-a.html

Currently rated 4.7 by 3 people

  • Currently 4.666667/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

TNG architecture model

September 8, 2008 23:21 by Orosz Gergely

The following article is intended to give an insight on the structure Sense/Net PortalEngine TNG focusing on object storage and management. This topic is a rather complex one, however, understanding this chapter is vital for efficiently working with objects stored in the Portal File System.

The architecture model

The TNG storage architecture consists of 4 separated layers.

More...

Currently rated 4.3 by 3 people

  • Currently 4.333333/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Finding a SharePoint alternative

August 18, 2008 18:06 by Tamás Bíró

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

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

PFS structure basics - for administrators and developers

July 31, 2008 09:48 by Orosz Gergely

PFS - entities in a tree

As mentioned before in a PFS review entry the Portal File System is an essential repository where all kinds of entities –documents, contents, custom objects, system files, images, style sheets etc. – are stored.

For the administrator with the help of the Portal Explorer these objects can easily be administered. Editing, adding, deleting and moving these entities is incredibly simple and straightforward. At the same time for the developer the PFS is the tool that makes the definition and handling objects a real ease.

Objects within the PFS are stored in a tree which makes the backend of the portal both structured and easily administrable. It also forces developers to organize the data stored within – the PFS was not designed to store a large amount of unstructured information but instead to efficiently manage structured entities and connections between.

More...

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Portlet adventures part I - say hello world

July 10, 2008 13:29 by Peter Zentai

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

Currently rated 4.0 by 4 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Expression based queries in the PFS

July 7, 2008 17:36 by Peter Zentai

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();

 

Currently rated 4.3 by 3 people

  • Currently 4.333333/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Unveiled: there's a machine in the ghost!

May 9, 2008 15:15 by Molnár Gergő

Recently I blogged about the dropping of the Pfs HttpHandler, and about a new HttpModule that creates a PortalContext instance for each request that should (could) be served from the portal.

There are excellent ASP.NET developers without any knowledge about these modules and handlers. They use the Web Forms / Web Controls infrastucture, and enjoy the magic called ASP.NET that makes this all possibe.
It's a very good thing - likely your customers don't think in HTTP requests and responses, authentication headers and abstract factories. You neither have to, and that's a big gift.

But if you're a developer like me, who always wants to know what's behind the scenes: this post is for you!
So, what's the magic? How the ASP.NET pages work? Not too surprisingly, there's no real black magic: there's a machine in the ghost.

Check out this figure:
 

In this figure you can see how the ASP.NET engine handles a HTTP request.

 

After the request routed to the ASP.NET from the webserver, the first step is to create a managed object model based on the request data. This is an internal and automatic function, you should not (and most likely would not) modify this procedure.

After that, there are blocks called "HttpModules". An HttpModule is a class that implements the IHttpModule interface. To implement this interface you have to write a method called Init(), and in this method you can subscribe to the HttpApplication event like Begin- and EndRequest, authenticate and authorize request, and so on.
In the event handler you can access the current HttpContext instance via the sender parameter, so you can access and modify the properties of the Request, the Response, the Session, the User, the Cache, etc properties, you can rewrite the actual URL and so on.
Each module is executed for each request, so if you got a task that should be done every time a new request come - for example authenticate the user - it should be done in a HttpModule.

You can inject your custom HttpModules into the ASP.NET module pipeline in the web.config:

<configuration>
 <system.web>
  <httpModules>
   <!-- SenseNet PortalEngine TNG Specific entries start -->
   <add name="PortalAuthentication" type="SenseNet.PortalEngine.Virtualization.PortalAuthenticationModule"/>
   <add name="PortalContext" type="SenseNet.PortalEngine.Virtualization.PortalContextModule" />
   <!-- SenseNet PortalEngine TNG Specific entries end -->
  </httpModules>
 </system.web>
</configuration>
 

After the modules finished their work and prepared the context, a reply should be generated to the reqest. This task is done by a HttpHandler.
The ASP.NET runtime selects the appropiate handler type, creates an instace of that type and let the instance do the work. In most cases the runtime selects the correct handler based on the extension, but you also can map a handler to a given path or HTTP verb (GET, POST, etc).

You've got two options if you want to write a custom HttpHandler. You have to implement the IHttpHandler or the IHttpHandlerFactory interface.

To implement the IHttpHandler you have to write a method called ProcessRequest. The current HttpContext will be passed to this method and you can generate your reply and use the Response.Write() method to send that back to the client.

To implement the IHttpHandlerFactory you have to write a method called GetHandler which returns an IHttpHandler instance based on the request type, url, and the translated path.

Here's a sample how can you insert your HttpModules (since we don't need the PfsHandler anymore that is commented out): 

<configuration>
 <system.web>
  <httpHandlers>
   <!-- SenseNet PortalEngine TNG Specific entries start -->
   <!--<add verb="*" path="*" validate="false" type="SenseNet.PortalEngine.Virtualization.PfsHandler"/>-->
   <!-- SenseNet PortalEngine TNG Specific entries end -->
  </httpHandlers>
 </system.web>

</configuration>

If you're a WebForms developer and you say "I've never-ever developed a HttpHandler!" then you're not right: the ASP.NET Page class implemets the IHttpHandler. When your ASP.NET page is served, an IHttpHandlerFactory handles the request by instantiating the appropiate type (your class derived from Page) and gives the control to that.

As easy as ABC, isn't it? 

Currently rated 4.5 by 4 people

  • Currently 4.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Categories: .Net
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Saying goodbye to PfsHandler

May 8, 2008 17:32 by Molnár Gergő

Hi Guys (and Girls) out there!

I'm Gergo, I'm a developer in the TNG team.

In the last few days I dived deep into the ASP.NET infrastructure. We had an HttpHandler-based solution for serving out ASP.NET pages from the PortalFileSystem. It started as a "quick-and-dirty but good enough for a software in alpha phase" solution. It was high time to replace it with a "clean and clear" one.
This implementation is based on a HttpModule (I dropped our HttpHandler, the default ASP.NET handler serves the pages - "keep it simple", aka "no woman, no cry"). Now there's a context object wich can be accessed via the PortalContext.Current property. If you're familiar with the HttpContext class, it must not be a big suprise... It makes the life much easier if we (you) want to add some extra URL rewriting and/or friendly URL handling functionality.

Although I could write pages about the technical details now I'm not going to do that. I started to work at 6:30 AM (it's quite uncommon), so it's high time to leave.
See you tomorow morning, till then here's a screenshot with a (finally!) working demo-product-page:

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Categories: .Net | Portal File System
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Mono screenshot

March 6, 2008 10:13 by Sándor Kiss

Although our current focus is getting the beta out as soon as possible, the team is also working on migrating the system to Mono.

The following screenshot is showing the Portal Explorer. Both server and client side is running on Linux with the latest nightly Mono build.

 

The implementation of Asp.net Ajax in Mono is brilliant. The Portal Explorer runs and behaves the same as in a Windows .Net environment.

Currently rated 5.0 by 4 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Porting Sense/Net Portal Engine TNG to Mono and Oracle

December 13, 2007 17:21 by Sándor Kiss
We have been developing on .Net for several years now. C#, the .Net class libraries, Microsoft SQL Server and the Visual Studio IDE are an ideal environment for developing business applications. The only drawback we have been struggling with was the dependence on the Microsoft Windows platform.

I have been checking out the Mono framework occasionally for the last two years. Our former portal version (Sense/Net Portal 5.5) had some glitches when we tried to run it on Mono. After two days of tweaking it did not run the way we expected. Some additional workarounds may have helped, but we gave up on it.

When we started Sense/Net Portal Engine TNG in our vision we have aimed for supporting more than one database server with the introduction of a database provider model in our data access layer. The Oracle port is closely following the original Microsoft SQL Server version.

Database independence is just one side of platform independence. Early in the development process we have downloaded the latest Mono sources from the SVN. Since Portal Explorer is the most complex part of Sense/Net Portal Engine TNG, we started to test Mono with that. Much to our surprise the data access and business logic layers were running without any problem. The GUI of Portal Explorer relies heavily on latest Asp.Net features (mainly Asp.Net Ajax). After some days of work the developers managed to run the GUI as well. We were really stunned and excited.

Sense/Net Portal Engine TNG is not 100% compatible with Mono yet. We desperately need some class libraries that are missing from Mono to achieve our goals. As a result the team has decided to implement the missing parts and contribute the results to the Mono project.

I will blog more about the topic later...

Currently rated 4.5 by 6 people

  • Currently 4.5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Bookmark and Share