Underlying Record is null

Developer
Dec 2, 2010 at 4:02 PM

Hi,

I've created my custom part (NewsletterPart), and a corresponding record - everything just like in the docs. Then, in the Migrations.cs I've created my own type (Newsletter - by AlterTypeDefinition) containing this part (.WithPart(...)) and some other parts (BodyPart, CommonPart). Of course I created corresponding driver and shape files (for display and edit).

Everything is working fine, but all the time I get NullReferenceException in NewsletterPart properties showing that underlying Record is null when Orchard is trying to render my EditorTemplate shape. All other parts get rendered correctly without any errors. Migrations.cs file is also correct (created by codegen).

Any clues? I tried almost everything, but the problem still exists:/ I'm using the latest dev source.

 

Cheers, Piotr

Developer
Dec 2, 2010 at 4:22 PM

I found out that LazyField, which should load Record is completely empty (_loader, _setter etc. are all null). What could be the cause?

Coordinator
Dec 2, 2010 at 4:26 PM

You need to register a Repository for the record, in a content handler, like this one:

using JetBrains.Annotations;
using Orchard.Blogs.Models;
using Orchard.ContentManagement.Handlers;
using Orchard.Data;

namespace Orchard.Blogs.Handlers {
    [UsedImplicitly]
    public class BlogArchivesPartHandler : ContentHandler {
        public BlogArchivesPartHandler(IRepository<BlogArchivesPartRecord> repository) {
            Filters.Add(StorageFilter.For(repository));
        }
    }
}

@Bertrand, could you check wherever a Record is described in the docs we also have this filter somewhere explained ?

Developer
Dec 2, 2010 at 4:36 PM

Hi!

Yep, found out that a minute ago and it worked, thanks. Stupid mistake - didn't have StorageFilter for this part...

But shouldn't be there some default storage filter set for every defined part-record couple (overridden if custom ContentHandler exists)? I understand that some parts don't need a repository and that's why I think about part-record couples. Having to write the same piece of code for every part, even the most simple, is not the best practice I think (DRY).

Cheers, Piotr