-
Notifications
You must be signed in to change notification settings - Fork 7
Plugin Architecture
When we originally designed Rit., we had some ideas of how we might implement a variety of “rich” content. Then we got real, simplified our design to focus on browser-safe content only and shipped it.
- Internationalized content, supporting the Rails i18n API
- Textile or Markdown
- ERB, HAML, mustache, etc.
- ???
When creating/editing a plate, we could allow the content creator the ability to specify properties of the content. This could either be a single property, or potentially a pipeline of properties. For example, you could interpolate the content with ERB and then render that result with Textile. Rit. could return a JSON response indicating the plate content itself, along with an indication of what the post-processing pipeline needs to be.
rit_client could then include methods to process content for each of the available options. After retrieving content from RIt. the client could process the content as indicated and return it. Since rit_client is a Rails plugin, you could even use helper methods in your Rit. content.
Example of this idea:
A Rit. plate could indicate that it needs to be parsed by ERB in the context of the page, as well as rendered by textile
In a Rit. plate, along with an indication that the post-processing pipeline is ‘erb’ and then ‘textile’:
h3. <%= some_helper_method(@obj) %>rit_client would receive a JSON response from Rit, something like this:
{
"content": "h3. <%= some_helper_method(@obj) %>",
"post-processing": ["erb", "textile"]
}
rit_client would then render the content with erb, and then render that output with textile and return the resulting content. Obviously this would mean every request for this content would be processed through that entire pipeline, which isn’t exactly fast.
We’re open to ideas on how to implement this. What do you think? What do you want to see?
Join the discussion here