theusualsuspect.com

I may repeat myself a bit here from the previous post regarding content editing, but I think it’s worth putting everything together in one post. This post has been written following more discussions with the team at the yorkshire based marketing agency I work at.

Content Types

All content items will be have a content type. Examples of content types could be News Articles, Exhibitions, Product Items etc.

Content Type will only be administered by “super” users. These will most likely be the developers working on a site.

The content type will control the forms displayed for editing each content item. This will be done by a content type being assigned to a “site” model. I have not decided whether this will be a view or domain model yet. This can be decided later.

When a user decides they wish to create a new news article Membrane will find the relevant content type and then, using reflection, the system will create the relevant form fields. This should mean that a large percentage of the time no extra editor plugins will need to be created. This will have the knock on effect of developers being able to spend time concentrating on the front end site they are creating and not writing new plugins for Membrane. Also if a site model gets updated Membrane should not need updating as it will simply create the necessary new field as part of the reflection.

As stated before the creation of form fields will be based on the convention over configuration principle. For more complex form fields a FormField attribute can be used.

An initial idea for the ContentType domain model can be found below:

	[ActiveRecord]
	public class ContentType : BaseModel
	{
		[Property(NotNull = true, Length = 200)]
		public string Name { get; set; }
 
		[Property(NotNull = true, Length = 200)]
		public string View { get; set; }
 
		[Property(NotNull = true, Length = 200)]
		public string Model { get; set; }
	}

Please note the use of the BaseModel class there. I’m planning that all models within Membrane and any sites using membrane will use the BaseModel. I’m also hoping that all forms required for Membrane, whether navigation editing, content editing, content type editing etc will run off the BaseCrudController, BaseCrudService and reflection idea. This should hopefully mean a lot less code needs writing all round.

Base Models

The team are currently considering having two “base” model classes. The BaseModel which everything will inherit from:

	[ActiveRecord]
	public class ContentType : BaseModel
	{
		[Property(NotNull = true, Length = 200)]
		public string Name { get; set; }
 
		[Property(NotNull = true, Length = 200)]
		public string Controller { get; set; }
 
		[Property(NotNull = true, Length = 200)]
		public string Model { get; set; }
	}

and the BaseOrderModel, which will be required by all things that need ordering.

We have already played around with a jQuery ordering plugin for UI purposes.

public class BaseOrderModel : BaseModel
{
	[Property]
	public int Order { get; set; }
}

Base CRUD Controllers and Services

Most editing will simply require the following actions:

• List
• New
• Edit
• Submit
• Confirm Delete
• Delete

For this reason the team believes that everything can run via the BaseCrudController and service. For things that need to be a little more complex then the Base functions can be extended.

Quick note on models with relationships

A lot of models will have relationships in them, such as Product Items and Product Types. The team intends to cope with this by using html select and combo boxes for a convention within the add/editing forms. We are also currently considering allowing the List actions to have filters for the relationships. So a user wanting to view the current product items list will be able to filter the list by product types. Again the List action will have to work all this out via reflection.

Hope this all makes sense. It was something I wanted to get out of my head and into writing as quickly as possible