4 ms·

Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-

Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API: http://www.gethifi.com/blog/first-we-built-an-api-then-we-built-a-cms http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu... That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint and trade-offs. Blog Engine CMSs are restrictive because they are Blog Engines! You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video.

noibl 15y ago
> You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video. The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.
- JoelSutherland 15y ago
  I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either: 1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time? 2. He was just indicating that headline in position X be 20px, communicating with the layout. 3. He was hard-setting it to 20px. It's probably #1. So if, as he says they switch layouts and output to tumblr, how would that work? Their answer might be a lot of manual work, or it could potentially be something really clever.
  - noibl 15y ago
    The semantic information is already in the selector that pops up, e.g. '.headline'. I don't see why they need to store anything elaborate to make that portable. The scope of the change (document, document type, section, site) isn't shown but presumably it defaults to 'type'. BTW the in-place edit features remind me a lot of this[1] use of Deface[2] in Spree[3] [1] http://www.youtube.com/watch?v=qjgQHzYcxIQ http://www.youtube.com/watch?v=qjgQHzYcxIQ [2] https://github.com/railsdog/deface#readme https://github.com/railsdog/deface#readme [3] http://spreecommerce.com/ http://spreecommerce.com/
dools 15y ago
Hey Joel, I remember seeing this post on HN ages ago and tried to find the link recently :) I wanted to show this "api first" approach to someone who was building an XML API for Flash sites. I showed him the Decal API [1] but wanted to give him this as an example a well, thanks for reminding me! [1] http://www.decalcms.com/page/Decal_API_Quick_Start_Guide http://www.decalcms.com/page/Decal_API_Quick_Start_Guide
bergie 15y ago
For the content management API, have you looked at Content Repositories? There are pretty good specs for standard content management APIs for Java (JCR), PHP (PHPCR) and Node.js (NoCR). The REST API alternative, CMIS, is unfortunately a bunch of committee-designed mess.
thomasfl 15y ago
The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy. Info about Vortex CMS (in Norwegian): http://www.uio.no/tjenester/it/web/vortex/ http://www.uio.no/tjenester/it/web/vortex/
- bergie 15y ago
  Sounds very good. Would the DAV (REST) APIs be accessible for something like https://github.com/bergie/VIE https://github.com/bergie/VIE ?
  - thomasfl 15y ago
    Yes it probably would. The API is also accessible from client side javascript. So you could create admin pages in 100% javascript like in HiFi.
    - bergie 15y ago
      Admin pages are one thing, but with VIE you can make content also editable right where it is. See for example what we did with Midgard: http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/ http://bergie.iki.fi/blog/introducing_the_midgard_create_use...
      - thomasfl 15y ago
        I really like the constraints you set on your project: "Build a CMS, no forms allowed". Aloha and other wysiwyg editors can hide the CMS almost totally. Using RDFa to store content is not a bad idea.
        bergie 15y ago
        If you're interested in integrating VIE into that system, then the EU-funded IKS Project might be able to help you with that: http://www.iks-project.eu/get-involved http://www.iks-project.eu/get-involved

noibl 15y ago

> You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video. The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.

JoelSutherland 15y ago
I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either: 1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time? 2. He was just indicating that headline in position X be 20px, communicating with the layout. 3. He was hard-setting it to 20px. It's probably #1. So if, as he says they switch layouts and output to tumblr, how would that work? Their answer might be a lot of manual work, or it could potentially be something really clever.
- noibl 15y ago
  The semantic information is already in the selector that pops up, e.g. '.headline'. I don't see why they need to store anything elaborate to make that portable. The scope of the change (document, document type, section, site) isn't shown but presumably it defaults to 'type'. BTW the in-place edit features remind me a lot of this[1] use of Deface[2] in Spree[3] [1] http://www.youtube.com/watch?v=qjgQHzYcxIQ http://www.youtube.com/watch?v=qjgQHzYcxIQ [2] https://github.com/railsdog/deface#readme https://github.com/railsdog/deface#readme [3] http://spreecommerce.com/ http://spreecommerce.com/

dools 15y ago

Hey Joel, I remember seeing this post on HN ages ago and tried to find the link recently :) I wanted to show this "api first" approach to someone who was building an XML API for Flash sites. I showed him the Decal API [1] but wanted to give him this as an example a well, thanks for reminding me! [1] http://www.decalcms.com/page/Decal_API_Quick_Start_Guide http://www.decalcms.com/page/Decal_API_Quick_Start_Guide

bergie 15y ago

For the content management API, have you looked at Content Repositories? There are pretty good specs for standard content management APIs for Java (JCR), PHP (PHPCR) and Node.js (NoCR). The REST API alternative, CMIS, is unfortunately a bunch of committee-designed mess.

thomasfl 15y ago

The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy. Info about Vortex CMS (in Norwegian): http://www.uio.no/tjenester/it/web/vortex/ http://www.uio.no/tjenester/it/web/vortex/

bergie 15y ago
Sounds very good. Would the DAV (REST) APIs be accessible for something like https://github.com/bergie/VIE https://github.com/bergie/VIE ?
- thomasfl 15y ago
  Yes it probably would. The API is also accessible from client side javascript. So you could create admin pages in 100% javascript like in HiFi.
  - bergie 15y ago
    Admin pages are one thing, but with VIE you can make content also editable right where it is. See for example what we did with Midgard: http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/ http://bergie.iki.fi/blog/introducing_the_midgard_create_use...
    - thomasfl 15y ago
      I really like the constraints you set on your project: "Build a CMS, no forms allowed". Aloha and other wysiwyg editors can hide the CMS almost totally. Using RDFa to store content is not a bad idea.
      - bergie 15y ago
        If you're interested in integrating VIE into that system, then the EU-funded IKS Project might be able to help you with that: http://www.iks-project.eu/get-involved http://www.iks-project.eu/get-involved