Parts vs. Fields vs. Types when creating modules.

Topics: Writing modules
Sep 20, 2014 at 7:18 PM
Creating my first module raises multiple questions, mostly about best practices and such.

One thing is that I'm not sure what is preferred among Parts and Types. I'm wrapping my head around it but still have a few thoughts.

Say I'm creating a Slider widget, so Slider is a collection of slides and a slide is a collection of elements. I'm thinking a element should be a Part. It includes metadata for the placement of the element within the slide but could be attached to multiple Content Types so i can have a textElement, imageElement and videoElement as needed ( I could define those Types I guess in the module as well, have it as a different Feature I guess). However the Slide is almost always the same, so I would like that as a Type, it holds some info though, like how long it stays, fadetime or something like that. Should these be fields or should I define these together as a Part?

Is my basic idea on the correct track?
Coordinator
Sep 21, 2014 at 4:25 AM
Well, in that particular case you'd first look for an existing module (there's Onestop.Slideshow for example). If your question is hypothetical and this is just an example, maybe you haven't chosen the simplest of examples. It really depends how far you'd want to go, and depending on that, there are several possible designs.
For instance, I don't think what you call an element should be a part: it seems like you'd want to be able to have any number of a given element on one slide. That's just one thing. A slide show module is really not something simple. If this is your first module, I would really consider going for something simpler. Not trying to discourage you, just trying to get you to have a gentler learning curve.
Sep 21, 2014 at 8:57 AM
BertrandLeRoy wrote:
For instance, I don't think what you call an element should be a part: it seems like you'd want to be able to have any number of a given element on one slide.
Any reason why not. I understand that there are already modules out but want to learn to do my own. Perhaps not simple but I feel confident I could do it withm the multiple tutorials online, the technical part hasn't bothered me yet its more the practices.

I'm not asking for a full on sample, just some tips on where my thinking is wrong. Is the Onestop.Slideshow open source? I could look into its source code to see how that is done.
Developer
Sep 22, 2014 at 9:36 PM
IngoVals wrote:
BertrandLeRoy wrote:
For instance, I don't think what you call an element should be a part: it seems like you'd want to be able to have any number of a given element on one slide.
Any reason why not.
The reason you don't want elements to be implemented as parts is that you can only have one part of a specific type per content type. So if you have a Slide content type, and some element implemented as a content part, you would only be able to add that element once to your slide. Instead, you might want to come up with some sort of elements system as is done with Onestop.Slideshows (which depends on Onestop.Layouts, which provides the actual implementation of an Elements framework).

You could also check out this post to get started :http://www.stevetaylor.me.uk/image-carousel-using-twitter-bootstrap-and-orchard-cms-projections
Sep 28, 2014 at 12:56 PM
sfmskywalker wrote:
The reason you don't want elements to be implemented as parts is that you can only have one part of a specific type per content type. So if you have a Slide content type, and some element implemented as a content part, you would only be able to add that element once to your slide.
Is that so? Does that not depend on how I define the collection part of it. I was thinking that the Slide Content Type would have a collection of other Content Types that had in common the fact they used a Element Content Part. I just wasn't sure how I would go around doing that in Orchard.

I will look at the OneStop and see how it works and then how the source code is.
Developer
Sep 28, 2014 at 9:59 PM
Edited Sep 28, 2014 at 9:59 PM
Sure, if your content part represents a collection of things, whatever those things are, then that is fine.
Sep 28, 2014 at 11:13 PM
sfmskywalker wrote:
Sure, if your content part represents a collection of things, whatever those things are, then that is fine.
So I would just define a 1 to N relation in the ContentPartRecord like any other Nhibernate project? Then tie it together in the driver/handler part using the ContentPicker somehow, or is there some specific method Orchard has defined for this scenario.

I would think that this is a common thing, Blog holds BlogPosts, Container holds Containable, but I haven't found a clear tutorial and the Core modules seem to have many advanced techniques so it can be hard to read between the lines.
Developer
Sep 29, 2014 at 2:57 AM
Edited Sep 29, 2014 at 2:58 AM
As you say, there are a few possible ways to go about this. The easiest way is to attach the ContentPickerField to your Slide content type, where each selected content item represents an element on your slide. But if you want to let the user control where each element should appear, then you need a more advanced implementation like Onestop.Layouts, or the upcoming Orchard.Layouts. Unless of course the Placement UI in the admin (where you get to position the individual shapes on a content type) suffices. Yet another way is to simply use the ContainerPart and ContainablePart, where you attach the ContainerPart to the Slide type, and the ContainablePart to your content types that you want to be able to add as an element to a slide.

So depending on what UX you're looking for, there are a variety of paths to take. It looks like it's finding a balance between ease of implementation but less control over , and potentially more cumbersome to use, versus a more advanced implementation but easy to use system.