SERIES: Writing an Orchard Twitter Widget - Define the requirements for the Widget and Global Settings (4)

SERIES: Writing an Orchard Twitter Widget - Define the requirements for the Widget and Global Settings (4)


This is part fourof the series about how we can create a twitter widget for Orchard. We will guide you through the creation of a custom Orchard module that will serve Tweets from the Twitter Timeline of a specific user.

  1. Introduction
  2. Setup and configure an Orchard environment
  3. Creating a new custom module
  4. Define the requirements for the Widget and Global Settings (4)

Our Orchard module in the end will contain a widget that renders tweets that are coming from a timeline from a specific twitter account. We need to store some settings on a more global level like the security tokens to actually authenticate against the Twitter API.

In this part of our series we will think about what we need to store and render regarding our tweets and settings.

Types, Parts, and Fields

Orchard is a very flexible system that lets you create Content Types on the fly. So for example: when you would need to store News items, you need to store specific values in the CMS. Orchard comes with some default parts that could be reused. If we look at the documentation, it takes Product as an example:

Orchard can handle arbitrary content types, including some that are dynamically created by the site administrator in a code-free manner. Those content types are aggregations of content parts that each deal with a particular concern. The reason for that is that many concerns span more than one content type.

For example, a blog post, a product and a video clip might all have a routable address, comments and tags. For that reason, the routable address, comments and tags are each treated in Orchard as a separate content part. This way, the comment management module can be developed only once and apply to arbitrary content types, including those that the author of the commenting module did not know about.

Parts themselves can have properties and content fields. Content fields are also reusable in the same way that parts are: a specific field type will be typically used by several part and content types. The difference between parts and fields resides in the scale at which they operate and in their semantics.

Fields are a finer grain than parts. For example, a field type might describe a phone number or a coordinate, whereas a part would typically describe a whole concern such as commenting or tagging.

But the important difference here is semantics: you want to write a part if it implements an "is a" relationship, and you would write a field if it implements a "has a" relationship.

For example, a shirt is a product and it has a SKU and a price. You wouldn't say that a shirt has a product or that a shirt is a price or a SKU. From that you know that the Shirt content type will be made of a Product part, and that the Product part will be made from a Money field named "price" and a String field named SKU.

Another difference is that you have only one part of a given type per content type, which makes sense in light of the "is a" relationship, whereas a part can have any number of fields of a given type. Another way of saying that is that fields on a part are a dictionary of strings to values of the field's type, whereas the content type is a list of part types (without names).

This gives another way of choosing between part and field: if you think people would want more than one instance of your object per content type, it needs to be a field.


So back to our own widget, what would we need to render tweets? In this case it isn’t necessary to store the tweets themselves into our database, although you could do that, but it would be nice to define what a tweet should look like in terms of properties.

On the other hand, we would like to store the security tokens into our database, but also some configurable properties for the widget itself. For example: how many tweets you want to show, should the tweets be cached etc. These properties could be different for every page you place the widget on.

Twitter Global Settings

Our global defined settings will contain the following properties:

  • Access Token
  • Access Token Secret
  • Consumer Key
  • Consumer Key Secret

    These properties are used to make a successful request to the Twitter API. But we add some extra properties to store some additional settings:

  • UserTimelineUrl
  • RateLimitStatusesUrl
  • CacheKey
  • CacheTimeOut

Twitter Widget Settings

Our settings per widget will contain the following properties:

  • ScreenName
  • NumberOfTweets
  • ShowReplyLink
  • ShowRetweetLink
  • ShowAvatar
  • ShowRelativeDateTime

These properties we want to store per page (per widget).

So, now we have defined what we actually want to store inside our CMS and what should be rendered. The next step will be to create the actual model classes and see how we can use a migration class to create the mapping between the database and the CMS.

Orchard uses NHibernate as its ORM (Object Relational Mapper). There are a few things we have to keep in mind, when working with NHibernate.

In the next post we will look into more detail on how to setup our migrations and define our Content Parts.

Stay tuned!

door Daniel Plomp


RadEditor - HTML WYSIWYG Editor. MS Word-like content editing experience thanks to a rich set of formatting tools, dropdowns, dialogs, system modules and built-in spell-check.
RadEditor's components - toolbar, content area, modes and modules
Toolbar's wrapper 
Content area wrapper
RadEditor's bottom area: Design, Html and Preview modes, Statistics module and resize handle.
It contains RadEditor's Modes/views (HTML, Design and Preview), Statistics and Resizer
Editor Mode buttonsStatistics moduleEditor resizer
RadEditor's Modules - special tools used to provide extra information such as Tag Inspector, Real Time HTML Viewer, Tag Properties and other.