The basic requirements of content management are to persist arbitrary structured data associated with a group of urls,
allow that data to be edited through a UI, and to provide that data to be inserted into a page template.
This is done in a clean light-touch way in Lynicon by simply extending the Route class. Lynicon provides a generic
DataRoute class, which when used, manages retrieval of an arbitrarily (within certain specifications) typed data item and
provision of it to the controller's action method via model binding.
The most basic scenario of content routing would then be implemented like this:
- Create a content type TestContent
public class TestContent : BaseContent
{
public string Title { get; set; }
}
- Register a DataRoute<TestContent> in RouteConfig.cs, sending requests to TestController action Index
...
routes.AddDataRoute<TestContent>("test", "test/{_0}", new { controller = "test", action = "index" });
...
- Add a parameter on the Index method of type TestContent named (by convention) 'data'.
public ActionResult Index(TestContent data)
{
return View(data);
}
Lynicon comes with 2 standard kinds of persistence. The default, as above, serializes content types before storing them in a dedicated database table along with metadata. This is Content persistence. Another kind exists called Basic persistence which simply stores each field as a database field, this is described elsewhere.
Content Types
The values of all readable and writeable public properties in a content type are persisted, unless they have the attribute JsonIgnoreAttribute applied to them.
Persisted properties must have values of the following legal types:
- Another type which is a valid content type
- A primitive type
- A generic list of legal types
A content type should ideally inherit directly or indirectly from BaseContent. It is possible to use a valid content type which does not, but certain operations cannot be performed on it.
Lynicon provides certain subtypes such as Image, Link, Video which should ideally be used for data representing values of those types, as the built-in editor will provide appropriate facilities if these are used.
Routing
The standard routing in MVC will send all urls matching the url string (subject to constraints) to the controller. The DataRoute<T> route will only match urls where a persisted data item of type T corresponding to the url exists.
DataRoute<T> uses convention to map url variables (e.g. {action}) to an address which specifies a particular data item to retrieve. The address is a tuple composed of all url variable values where the url variable is underscore followed by a number, starting zero. E.g.
shops/{_0}/{_1}could be a url pattern for shops where the town they are in matches {_0} and the name of the shop matches {_1} e.g.
shops/brighton/berts-fish-and-chips
If there are no url variables e.g. for the home page where the url is the empty string, there is only one (or zero) data item for the route.
Lynicon supports a use pattern where multiple data routes with different types have the same url pattern. This allows differently typed content items to exist within the same space of urls.
Editing
User management is a core part of Lynicon. This means that you can always log in to a Lynicon site on the url /lynicon/login. Once logged in with Editor role, routing behaves differently. For a url backed by an existing persisted data item, Lynicon will now show you an editor when you navigate to that url. The default editor is a right hand side panel with the current page displayed to the left.
For a url without a data item, navigating to it shows you a blank editor as before, with an indication that no page exists at this location. If you fill in data and save it, because there is now a persisted data item for this page, the next time you view it it will be as above.
Add Comment