Question

Im trying to create a hive provider that would be able to work towards some objects.

An object may look something like this

public class MyContent
{
    public System.Collections.Generic.List Content { get; set; }
}

public class ContentExample
{
    public string Title { get; set; }
    public string Text { get; set; }
}

public class MyFiles
{
    public System.Collections.Generic.List Files { get; set; }
}

public class FileExample
{
    public System.IO.FileInfo File { get; set; }
}

I’ve downloaded and checked the two Hive providers from the Visual Studio Gallery (Umbraco 5 Hive Provider and Umbraco 5 Simple Hive Provider), but the lack of documentation is a bit disturbing. I also downloaded some of the other example hives, like the WordPress hive provider, but that one is rather different from the ones in the Visual Studio Gallery.

The Idea

Im used to working with stuff like ObjectDataSource, the example above could be complemented with full CRUD if required.

Now, I assume one Hive provider would be able to serve different parts of Umbraco with content (right?). Just set up a new Repository and go? I have now clue how to connect all parts or even how to get the data into the provider yet.

Any help in how I could bring all pieces together?

Thanks

Answer 1

The first step is to take a step back and evaluate your business requirements. Will you allow for users to be updating the information with forms in the frontend? Do you need a tree editor for the content in the backoffice? Do you need to be work with data outside of the built-in ORM?

If the answer to these is no, a hive provider is overkill. Evaluate solutions using either a simple surface controllers, or just a custom document type. Umbraco 5 is a full EAV/CR system, so unlike some CMS products, you’ll be able to represent any rdbs structure you can imagine

ContentExample could be represented be a document type called ‘Article’, which has properties Title and Text. Just by defining this document type we’re instantly given add and edit forms for our back office users in our content section. We can even restrict which nodes are able to have children of type ‘Article’, e.g News.

In the same way, an upload control is a field type that allows you to attach files to your document.

So what’s point of a custom hive provider?

The goal of a custom hive provider is to unify CRUD actions for data access layers.
As a result data can be stored in the baked-in nhibernate orm, custom tables, rss feeds, or even flat files, while still using a common interface to retrieve and update it. If this sounds like what you’re aiming for, read on.

Going back to the business requirements, specifically, where do you want to actually store the data?–Given that you have some fields and properties related to flat file storage, let’s say that one TypedEntity (a model) is equivelant to one file and write some pseduocode:

The first step, is as you say ‘get the data into the repository.’ This involves going back to that VS template and filling in the ‘not implemented’ methods with your logic for storing and retrieving data.

    protected override void PerformAddOrUpdate(TypedEntity entity)
    {
        // step 1: serialize the typed entity to xml
        // step 2: write the file to the hdd, making sure that the file name is named using the                 hive id so that we can pull it back later.
    }

Once you’ve written the data access layer, or DAL, you can hook it up in the hive config, giving it url to match. e.g. rather than matching content:\\, yours might match on file-manager:\\

We can allow our backoffice users to be able to add new entities (indirectly, new files) by writing a custom tree, and we can display the results to our front-end users via macros.