Elaborate ContentPart and ContentPartRecord modeling

Topics: Writing modules
Jan 4, 2012 at 2:07 PM

I'm having trouble modeling a contenttype that contains a lot of lists-like functionality. My use-case:

ContentType Homepage should contain a list of "offers", each has 8 string fields. Also it should have a list of "banners", each having 3 string fields, and a list of .. lists. Modeled:

  public class Homepage
  {
    public IEnumerable<Offer> Offers { get; set; }
    public IEnumerable<MiniOfferList> Banners { get; set; }
  }
  public class Offer {
    public string Title { get; set; }
    public string Image { get; set; }
    public int Price { get; set; }
  }
  public class MiniOfferList
  {
    public string Title { get; set; }
    public IEnumerable<MiniOffer> Offers { get; set; }
  }
  public class MiniOffer {
    public string Title { get; set; }
    public string Image { get; set; }
  }

Because it's only a few strings, for the editors it would be nice if they just go to the Homepage contentitem and see all the offers and minioffers beneath eachother, and can edit them. But I can't wrap my head around how to get there. Is it possible to have multiple database tables for one contentpart(record)? In the back-end I would then create a "+" button to add a new Offer to the list, and it should result in an insert statement to the Homepage_Offer database table.

The alternative is that I create a contenttype for an offer and a minioffer, and use the projector module to display lists of both on my Homepage. This would also be difficult because MiniOfferList is a list of lists :S

I can't imagine I'm alone in this feature request, so hopefully somebody can help me out!

Coordinator
Jan 6, 2012 at 7:22 AM

Please read this: http://docs.orchardproject.net/Documentation/Creating-1-n-and-n-n-relations


Jan 16, 2012 at 8:26 AM

Stupid that I didn't think of that! My colleagues ended up creating a n-1 relation and it works perfectly!

Downside is that there's quite some code needed for the "add" and "delete" functionality, we created our own controller and routes for this purpose.
Due to some nhibernate problems using TryUpdateModel we also had to write our own save logic. But hey, in the end it works!