It has been a month since Sitefinity 4.0 hit the streets. Many miss the features and marketplace extensions for 3.7 that took years to ripen. That’s why today I am going to show you how to migrate your custom modules from Sitefinity 3.7 to 4.0.

For our 3.7 custom module, I will use the Contacts Module sample Ivan built. We should have a Contacts Module for Sitefinity 4.0 by the end of this article. Let us first look at the 3.7 graphic interface and project structure that we will start from:

Notice in the sample there is a completely separate project for the old Nolics data layer. Fortunately, our new Sitefinity 4.0 will have one project since the new OpenAccess ORM is baked right into the architecture.

If you have not done so already, install the Sitefinity 4.0 SDK. The included Products Module sample will be our guide for creating the Contacts Module architecture. It will be more than our guide… it will be our module template! At the time of this writing, there is only a Visual Studio template for the Sitefinity Intermediate Module. An advance OpenAccess Visual Studio template would be killer though and is probably in the works.

Now that we have the background for our mission, let’s create a project for our Sitefinity 4.0 Contacts Module. To get a huge head start on this, I copied the entire Products Module into our new solution. I replaced the word "Product" to "Contact" from all namespaces, classes, properties, methods, file names, and even strings and comments (remember to use case sensitivity when doing this). It is a tedious journey with some fixes along the way. At the time of this writing, there were problems with the Products sample’s taxonomy, revision history, comments, and embedded template (some have been fixed already).

After some tweaking, below is the project structure and graphic interface that I ended up. No code has been migrated yet, but rather this is our starting point for the Sitefinity 4.0 Contacts Module.

Compiling the project and add the DLL into your Sitefinity 4.0's bin folder. You can now register the new module so it gets installed onto your site with these settings:

You should now see it in the administration screens, specifically in the "Content" drop down across the top (remember to restart the app if needed). This is where you will access the new module.

There is also a new toolbox section for your module while doing page editing. This control will display your contacts with templates that originally came with Sitefinity 4.0. I copied these default templates into the project and tagged them so I know that they are indeed being used.

Migration Strategy

Everything is in place and we are ready to migrate! The strategy here will be:

1. Create properties needed for the contact
2. Programmatically create admin pages
3. Adjust public control templates
4. Move resource messages (if applicable)
5. Create control designers (if applicable)

New Way of Meta Data

The cornerstone to any Sitefinity module is the custom properties used for content items. In 3.7, these properties were called meta data and were added in the web.config. In 4.0, the meta data is defined in the properties of your persistent entity, which is called a "model".

The 3.7 Contacts Module did not leverage the available meta data architecture, but instead illustrated the use of Nolics, the prior ORM that was built into Sitefinity:

Since it is rare to dig into Nolics for Sitefinity 3 modules, I would like to also show how this would be represented as meta data:

In my new Sitefinity 4.0 Contacts Module, I am going to copy these as properties of the contact entity. I will take this one step further and create an Interface for the entity to enforce these properties elsewhere in the project or solution.

Notice the localization types for the position (aka title), summary (aka responsibilities), and content (aka bio, description, etc) properties. To simplify the sample for this article, I will leave out the department property since I would like to discuss this in a part 2 segment. This involves a whole other can of worms relating to parent/child relationships and taxonomy. I plan on replicating the category taxonomy to associate a contact with their department(s). Stay tuned for that!

It is now time to implement this Interface on the contact model and service view of the Sitefinity 4.0 Contacts Module. Make sure the necessary classes inherit the Interface:

In the code for ContactItem, you will notice that localization strings are handled a bit differently. The field members have a "Transient" attribute and its associated property has a “Datebase” attribute which defines the underlying column type. For ContactItemViewModel, notice you have to use the “GetString” extension for initializing the localization string values. Remember to update the ContactsManager.Copy method to include all these properties.

The Graphic Interface

Next step is to add input fields for the new properties of the contact item. The backend interface is handled differently than the frontend. Let us first start with the backend.

In the new Sitefinity 4.0 Contacts Module, go to ContactsDefinition.CreateBackendSections. This is where field controls for your contact are created in the admin interface. Some are already created for us by the Products Module sample, but we will want to add new inputs for summary, first name, last name, phone, email, photo, etc. Check out how the below interface was created programmatically:

We will also add new columns for the admin contact list. To do this, DataColumnElements must be added to the grid view in ContactsDefinition.DefineContactsBackendContentView. Notice how Lstring (localized properties) must be handled a bit differently again. Just add “.Value” to the client template binding.

Now that we have all our fields and admin interface, we are ready for the frontend interface. Let's first tackle the ContactListView template.

The out-of-the-box template for the frontend content list has irrelevant information, such as who the author is. We will modify the template to include information such as name, position, photo, and summary. In part 2 of this blog post, we will make these configurable so you can easily show/hide properties from the page edit level.

And finally, we will modify the contact detail page to display name, position, phone, email, description, and photo.

Conclusion

So at this point you are probably wondering where the "migration" part is… It seems the meta keys, templates, and entity interfaces are the only areas that can be reused. If you need to migrate more logic, try isolating your old methods into static helper classes; put them into a different library all together. It becomes the art of object oriented programming from that point. Portability is how coders should think anyways (never duplicate code, even across solutions). So use this opportunity to refactor.

All is not lost though. You now get to extend the database via code, automatically have web service capability, have an elaborate taxonomy, and someday multi-tenancy. Sitefinity 4.0 definitely raises the bar and we are only seeing the tip of the iceberg!

Downloads

• Sitefinity 3.6 Contacts Module
• Sitefinity 4.0 Contacts Module

Known Issues

Sitefinity 4.0 is a work in progress and many new fixes and enhancements are made everyday. The Products Module and documentation will be updated by Sitefinity in the next release. At the time of this writing, some issues exist and will be fixed as they are released. Remember to check back for updates!

• Fix comments
• Fix revision history
• Photo element control not implemented
• Use embedded templates from your own assembly
• Add department relationship
• Add more admin filtering options
• Add contact download options
• Add designer to frontend controls

Source Code

The complete source code of this module is available for purchase on the Falafel Store for $29.