Content types

Topics: General
Mar 26, 2011 at 8:09 PM

This is a conceptual question (I really think there should be a seperate topic just for conceptual).

I just had a duh! moment where I slapped my forehead ;-)

I had been under the (I believe) misconception that the term page in Orchard was being used in a similar fashion to the way it is used elsewhere.

Now I realise that an Orchard page is just another type of content, just like a list. Further there is nothing special about a page, it is just like any user created content type.

This of course is totally different to every other part of the web where virtually always a webpage contains content.

What I don't understand is why does the Dashboard treat a blog as a something other than content? Isn't a blog just another content type?

So why for example can't I click on Content then Create New Content to create a blog?

Or is this just perhaps security through obscurity?

Mar 26, 2011 at 8:32 PM
Edited Mar 26, 2011 at 8:37 PM
JonnyBoats wrote:

This is a conceptual question (I really think there should be a seperate topic just for conceptual).

I kind of think there are too many topics ... it's really hard to track new posts, especially when a lot of things get posted in multiple topics :)

Anyway, you're pretty much spot on about content. The default Orchard installation (or the Recipe in 1.1) creates some content types for you (Page and List obviously; but there are other ones hidden away such as User). You are free to customise these content types in any way you want. What makes a Page actually page-like are the Routable and Body parts.

Blogs and Blog Posts are also just content types. A module can define its own content types and compose them out of any available parts. There are two special parts that the Blog module comes with: BlogPart and BlogPostPart.

The reason you can't create your own Blog content type from scratch is simply because the BlogPart and BlogPostPart aren't available in the list of attachable parts. That's normally done in Migrations.cs where you have a command like this:

 

ContentDefinitionManager.AlterPartDefinition(
                typeof(BlogPostPart).Name, cfg => cfg.Attachable());

However because the blog module is lacking those lines, you can't "roll your own". But you can still customise Blog and BlogPost in the Content Types section of the Dashboard, you'll just notice you can't remove the Blog or Blog Post parts.

Why do Pages show in the New menu and get listed in Content Items, whereas Blogs don't? I think it has to do with this from Migrations.cs in Orchard.Pages module:

 

            ContentDefinitionManager.AlterTypeDefinition("Page", 
                cfg=>cfg
                .WithPart("CommonPart")
                .WithPart("PublishLaterPart")
                .WithPart("RoutePart")
                .WithPart("BodyPart")
                .Creatable());

 

I think it's the .Creatable() command (and nothing else) that differentiates it from blogs and blog posts.

I'm not sure of all the reasons for doing it this way. In part I think it's because the Blog module comes with its own admin UI and it'd be redundant to have two ways of managing stuff. Also the Content Items screen would quickly get out of control if 10s or 100s of blog posts were there mixed in with all your other content. But I can't see any real reason to prevent custom types of blog and blog post from being created. Maybe you could experiment with making those parts attachable and see what happens? ...Not on a production site of course, in case things blow up :)

Hope that helps explain!

Coordinator
Mar 26, 2011 at 9:41 PM

Blogs were developed before we had the full type system. It’s been our intention for quite some time to unify blogs and posts with lists and items, but we have not found the time to do it yet. It will happen at some point though.

Mar 27, 2011 at 12:16 AM
BertrandLeRoy wrote:

Blogs were developed before we had the full type system. It’s been our intention for quite some time to unify blogs and posts with lists and items, but we have not found the time to do it yet. It will happen at some point though.

ALL content types ARE EQUAL, BUT SOME content types ARE MORE EQUAL THAN OTHERS.

with apologies to George Orwell ;-)

 

PS: Is there a work item for this?

Coordinator
Mar 27, 2011 at 4:29 AM

Eh. Here's the work item: http://orchard.codeplex.com/workitem/16780

Mar 27, 2011 at 3:43 PM

"Why do Pages show in the New menu and get listed in Content Items, whereas Blogs don't? I think it has to do with this from Migrations.cs in Orchard.Pages module:"

Lets see if I understand.

In theory at least, it should be possible in the Dashboard to create a new Content Item of any Content Type once work item 16780 is complete?

 

Mar 27, 2011 at 6:19 PM

That's not what workitem #16780 is about.

Currently, there is a Container/Containables system which allows you to create a content type that can contain another type.

Basically, that's what Blogs are doing - a Blog contains BlogPosts.

But because the Blogs module was created prior to the Containers system, it uses its own mechanism for linking blogs to blog posts, it doesn't go through the Containers route.

What Bertrand and the workitem are saying, is that the Blogs module is due to be refactored so that it does use the Containers system. Doubtless this will also require some refactoring of the Containers to support some of the additional functionality that Blogs currently have. This will likely then mean that you could roll your own Content Type that behaves to all intents and purposes just like a Blog.

It will still be possible for a module to provide a Content Type that you cannot create through the "New" menu. There are a lot of reasons why module authors might want to enforce this (although in general the best practice is to provide parts that can be reused anywhere - it's sometimes just going to be harder to do things that way). Work item #16780 is just bringing one module more in line with the composability architecture.

Mar 27, 2011 at 10:49 PM

Allow me to take another stab at Content Types.

Out of the box Orchard comes with three(3) routable (that is they include the Root Part) Content Types, namely Page, List and Blog.

Also included are some Widgets, which happen to be non-routable (the ones in the box at least do not include the Root Part).

Characteristics of a Widget include:

  1. It includes a Widget Part.
  2. It is created with cfg.WithSetting("Stereotype", "Widget")
  3. It does not include a Root Part.

Do all three of these statements necessary hold for all possible widgets or could a widget include a Root Part for example?

Finally I assume I could create a new content type that was not a widget and did not include the Root Part. If it included the Containable Part I could use it's contents in a Widget for example?

Mar 27, 2011 at 11:31 PM

Let me just clarify: it's Route not Root :)

In theory you could add Routable to a Widget. I don't know what this would do; maybe the widget would display in the standard Content zone on that page. Or maybe the world would explode!

Yes you can create content types without Routable. Comments are one built-in example, and I've seen other modules use non-routable content types.

Anything with Container (not Containable) can be used in the Container widget. They don't have to be Routable.

Routable just describes the process of mapping a URL to a particular content item. Since widgets use a different layer-based method of visibility, they don't have anything to do with routes.

Mar 28, 2011 at 12:07 AM
randompete wrote:

Let me just clarify: it's Route not Root :)

In theory you could add Routable to a Widget. I don't know what this would do; maybe the widget would display in the standard Content zone on that page. Or maybe the world would explode!

Yes you can create content types without Routable. Comments are one built-in example, and I've seen other modules use non-routable content types.

Anything with Container (not Containable) can be used in the Container widget. They don't have to be Routable.

Routable just describes the process of mapping a URL to a particular content item. Since widgets use a different layer-based method of visibility, they don't have anything to do with routes.

Yes - me bad ;-) I meant to type Route.

I don't understand "In theory you could add Routable to a Widget. I don't know what this would do; maybe the widget would display in the standard Content zone on that page."

The part I am hung up on is "that page" Isn't a Page in Orchard just one of the many Content TypesWidgets get added to Zones, not Content Types, correct?

"Anything with Container (not Containable) can be used in the Container widget." Isn't this backwards? The Widget or Content Type would have the Container Part (Like the List Content Type that ships with Orchard). The group of "things" being included in the summary need to have the Containable Part.

Mar 28, 2011 at 1:23 AM
- When I said page just then I meant webpage or URL. I think the Page content type could be better renamed to Article to avoid confusion. Widgets get applied to Zones based on Layer rules. But there are other ways to push things to zones; and one thing Routable does is push content to the Content Zone. So what I was saying was that if you applied Routable to a Widget, then on that Url you might get that widget in the Content Zone.

- The Container Widget is a widget for displaying Containers. Just like the Html widget is a widget for displaying Html. This makes sense when you think about it.

I'm only describing what I find out as I experiment with these different parts. Do the same; experiment with all this stuff and see what it does.