ClientPages

---

Ever heard: "can we change the text on the homepage by ourself?"

---

with client_pages you can separate your content from html markup and css styles, by extracting it to simple markdown files.

use it for small content parts of your app which need to be updated regulary by someone or outsource all your content together, it's up to you.

"the principle is really easy. at the place where you call render_content(:foo), the renderer will grap the markdown file content/foo.md and render it as html. by passing a block to render_content the generated markup can be modified."

the main benefit of doing this: anybody can change the content, without the need for an admin backend and stuff like this. just make it possible for them to edit the files.

from the beginning client pages was built for supporting remote files. an easy example could be a public shared dropbox folder (or anything that can deliver files),

a sample configuration could look like this: here we set bla = true to enable ...

btw, the core markdown parser is redcarpet and you can customize the behaviour of it like you would normaly do by setting renderer and extensions through the config. (~ naaa, formulierung)

but the power of client_pages comes from its helper methods for rendering content

simple example

imaginge you have this markdown file: insert markdown here

Let's say you want a class on each list item, and a data attribute on that link. And maybe a 'active' class on any link, when it's the current path? It would also be nice to wrap each paragraph in a container?

we can accomplish all that by just giving the render_content(:file) method a block and tell the content builder to do that for you. insert haml here

if configured render_content work with raw markdown, instead of a file name.

this way, you can add a lot of behaivour by leaving your markdown content just as content with raw structure, and the main markup and styling stays in your views.

Installation and setup

Add this line to your application's Gemfile:

gem 'client_pages'

And then execute:

$ bundle

Or install it yourself as:

$ gem install client_pages

rails project?

add a content directory and your done, per default it's content maybe you like to configure this to app/content or app/views/content totaly up to you.

no framework? pure rack?

for convenience you can add include ClientPages::MarkdownContent to your application controller/view_helper/presenter/... or something which is responsible for building html so that you can call render_content there.

or if you're riding the real blank slate, just call ClientPages.render_content directly.

sinatra?

mini example

renderer

if you call render_content without a block it just renders the markdown to html

  ```render_content('posts/index')```

### known issues

  ```<% end.html_safe %>```
  Oups? => http://bibwild.wordpress.com/2013/12/19/you-never-want-to-call-html_safe-in-a-rails-template/

### builder
  - modify
  - wrap
  - switch?

### matcher
  - implicit attribute match
  - explicit match
  - content match? (hole file?)

### config
  config.ru file or initializer

  - by default...
  - content_path
  - if you go the full remote path without fallback, you might consider to turn on caching.
  - s3 ?

ClientPages.configure do |c| c.remote = true c.remote_content_path = 'https://dl.dropboxusercontent.com/u/363312/rackedy_rack' c.content_path = 'content' c.caching = true c.render_options = { hard_wrap: true, with_toc_data: false, } c.markdown_extensions = { tables: true, autolink: true, lax_spacing: true, space_after_headers: true, underline: true, no_intra_emphasis: true, } end

### i18n
  per default client_pages looks in your content_path for /locale/...
  - is the locale a config_setting?
  - how to tell client_pages the locale?

  hm, or where is the problem? ```render_content("#{my_locale}/posts/index")```

### caching
  the current implementation it the easiest way to do something like caching.
  it's really simple and lives as long as the process runs, as it's nothing more than a hash that doesn't get persistet.
  so it can not be shared between processes.
  and because one of the [hard things in Computer Science](http://martinfowler.com/bliki/TwoHardThings.html) is _cache invalidation_
  you can flush the cache also at runtime with

  ```cache.clear```

  So if your're curious about caching, you should take care of that by yourself and cache the complete render_content block for example.

### commands
  - downloader!!!
  - cache killer?

----

## Contributing

Contributions are always welcome! Doesn't matter if you fix just a typo, add some documentation/tests or refactor hole parts of the code.
As this gem is in early development, there are a lot of low hanging fruits.

+ Fork it
+ Change it
+ Test it
+ Commit it
+ Push it
+ Pull Request it