This project is read-only.

Best Starat for a "Total Newbie" in Orchard Docs

Topics: General
Dec 17, 2011 at 8:57 AM



1.     Site Settings:A site in Orchard is a content item, which makes it possible for modules to weld additional parts. This is how modules can contribute site settings.Site settings are per tenant.

2.     Event Bus:Orchard and its modules expose extensibility points by creating interfaces for dependencies, implementations of which can then get injected.

i.                Plugging into an extensibility point is done either by implementing its interface, or by implementing an interface that has the same name and the same methods. In other words, Orchard does not require strictly strongly typed interface correspondence, which enables plug-ins to extend an extensibility point without taking a dependency on the assembly where it's defined.

This is just one implementation of the Orchard event bus. When an extensibility point calls into injected implementations, a message gets published on the event bus. One of the objects listening to the event bus dispatches the messages to the methods in classes that    derive from an interface appropriately named.

1.      Orchard Core: The Orchard.Core assembly contains a set of modules that are necessary for Orchard to run. Other modules can safely take dependencies on these modules that will always be available.Examples of core modules are feeds, navigation or routable.

2.     Content Type System: Contents in Orchard are managed under an actual type system that is in some ways richer and more dynamic than the underlying .NET type system, in order to provide the flexibility that is necessary in a Web CMS: types must be composed on the fly at runtime and reflect the concerns of content management.

3.      Types, Parts, and Fields: 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.

i.                    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.

ii.                  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.

iii.                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.

iv.                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.

v.                  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.

i.                    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.

ii.                  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).

      viii.    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.

6. Anatomy of a Content Type: A content type, as we've seen, is built from content parts. Content parts, code-wise, are typically associated with: * a Record, which is a POCO representation of the part's data * a model class that is the actual part and that derives from ContentPart<T> where T is the record type * a repository. The repository does not need to be implemented by the module author as Orchard will be able to just use a generic one. * handlers. Handlers implement IContentHandler and are a set of event handlers such as OnCreated or OnSaved. Basically, they hook onto the content item's lifecycle to perform a number of tasks. They can also participate in the actual composition of the content items from their constructors. There is a Filters collection on the base ContentHandler that enable the handler to add common behavior to the content type.
For example, Orchard provides a StorageFilter that makes it very easy to declare how persistence of a content part should be handled: just do
Filters.Add(StorageFilter.For(myPartRepository)); and Orchard will take care of persisting to the database the data from myPartRepository.
Another example of a filter is the ActivatingFilter that is in charge of doing the actual welding of parts onto a type: calling
Filters.Add(new ActivatingFilter&lt;BodyAspect&gt;(BlogPostDriver.ContentType.Name)); adds the body content part to blog posts. * drivers. Drivers are friendlier, more specialized handlers (and as a consequence less flexible) and are associated with a specific content part type (they derive from ContentItemDriver<T> where T is a content part type). Handlers on the other hand do not have to be specific to a content part type. Drivers can be seen as controllers for a specific part. They typically build shapes to be rendered by the theme engine.

Dec 18, 2011 at 3:04 PM

No offense, but am I the only one who feels this user is trolling this board?

Dec 18, 2011 at 4:21 PM

I couldn't work it out, 786basharat is this documentation you've written or did you copy/paste it from somewhere for explanation? If you've written it, it looks pretty good, and you should perhaps simply add it the wiki on rather than post it here...

Dec 18, 2011 at 5:06 PM

All of what he posted above comes from this page: