This project is read-only.

Content Parts and Content Fields

Topics: Customizing Orchard, Writing modules
May 5, 2015 at 5:25 PM
Edited May 5, 2015 at 5:25 PM
I have read a great deal about writing modules for Orchard, however I am still puzzled by the need for the distinction between Content Parts and Content Fields. The Content Type could be composed of a list Content Fields, then that Content Type could be consumed by another Content Type and so on. This also removes the seemly arbitrary limit of one Content Part per Content Type.

I followed the instructions on writing a map content part at "" and it worked well. However, if I wanted a page that contained multiple maps I could not use a content part; I would need to rewrite it as a Content Field. So I am still trying to understand the need for Content Parts and their distinction with Content Fields.
May 5, 2015 at 9:02 PM
May 5, 2015 at 9:19 PM
Well, that has confused many users over the years, and while the theoretical justification stands, in the end, it would have been a better decision to have just fields, and have a bit on some of those that says "only one of that is allowed". This way, we would have removed the confusion, while retaining the uniqueness aspect where it makes sense (autoroute, title, etc.). And guess what? That's exactly what I did when I designed DecentCMS ;)
May 5, 2015 at 9:58 PM
Thank you for your input. In order to create a path from SharePoint to Orchard I am looking at all the functionality I need to replace. I have about a dozen SharePoint web parts (gauges, indicators, graphs, grids, etc..) that I need to rewrite/port to the MVC framework that Orchard uses. I originally thought that I should focus on building Content Parts, however all of the parts NEED to appear on a page 1-N times. So I have started to look at making them Content Fields which seem to be less restrictive. Is there any real draw backs or problems related to this approach?

Bertrand, I have read everything you have written about DecentCMS, it seems more straightforward I just wish the development was further along. I would like to finish the transition away from SharePoint by the end of this year so I need to focus on replacing the webparts functionality. Out of all the CMS systems I have looked at Orchard seems to be the closest fit, and it is a bonus that it is still an active project.
May 6, 2015 at 1:36 AM
Yes, I'm not suggesting anyone use DecentCMS at this point ;) I was just illustrating...

So where do these gauges get their data from? I'm asking, because usually, the closest thing to web parts are widgets. Amusingly, many years ago, I worked on WebParts.
May 6, 2015 at 4:37 PM
I had originally thought that I should be designing widgets but that will not work because widget are not page specific controls. A good example of a requirement, I need a page with four gauges, a chart, and a paragraph of text. This is very typical of the type of page I need.

Currently the gauge web part reads a XML configuration file from a SharePoint Document library which tells it how to display itself and what stored procedure to call for the value. The web part reads the config file and generates a .png file which is sent back to the browser. Therefore, I may create a Gauge Content Field Type that takes a configuration file path as a parameter and reproduces the same functionality.

Next, I need to deal with the replacing the SharePoint Document library functionality. I have look at the media library but it seem to be gear for pictures or music, also I need to allow users to upload/download files without giving them access to the admin section. I look at FileManager in the Orchard gallery but I could never see how to use it or whether it even works in 1.8.1. There is a possibility of fixing/altering that module to meet my needs. I have also thought about porting into Orchard.

These are some of the issues I am currently facing. Any input you have about this or other issues regarding move to Orchard I would find very helpful.
May 6, 2015 at 6:48 PM
When you wrote "page specific widgets" I immediately thought of the Orchard.Layouts module. One can create custom elements (like eg. gauges, charts) that can be placed within a page layout.

Summoning @sfmskywalker - he should be able to shed more light on it.
May 6, 2015 at 8:31 PM
Like Piotr, I too instantly thought Orchard.Layouts - it seems perfect for the scenario you described. What you would write as web parts in SharePoint, you'd implement as Elements in Orchard. Elements can be placed onto a canvas (which has layouts support using a grid system).

Regarding document library functionality, you'd have to implement that yourself. We did something similar (although very simplistic) for Orchard Pros where we allow users to upload files and attach them to tickets (still leveraging Media Library's APIs, but exposed through custom controllers). You probably need something more elaborate, but I think this shows Orchard's flexibility and integrability.
May 6, 2015 at 10:16 PM
I was thinking that Part is actually a bad name. Not sure I haven't seen it in one of Bertrand's posts, but Trait or even Mixin and Aspect might be better than Part.
May 6, 2015 at 11:11 PM
I think I remember reading somewhere that at some point Aspect was renamed to Part, except for the abstractions (ITitleAspect for example).
Just out of curiosity, why do you think Part is a bad name?
May 7, 2015 at 3:12 AM
Yes, those alternatives look more abstract. Filed looks like something too simple, such as a text filed or a date field, whereas we are manipulating something just one step above that. I like content part.
May 7, 2015 at 3:51 PM
Thank you for the input. Are there any demos or guide lines for creating Elements? The Layouts in 1.9 look really nice, is there any documentation or tutorial on how to use the Layouts?

It looks like the file system is the only thing that needs major design work. I will probably need to codify my needs and then see what API calls I can use in Orchard.