Skip to content
balupton edited this page Jun 18, 2012 · 1 revision

Alrighty. So after some more though, I'm settling on the following for the time being.

Plan of attack:

  1. Get the REST plugin working, with GET/POST/PUT/DELETE on actual resource urls. As well as a formal rest API such as GET /rest/database/ for listing and GET/POST/PUT/DELETE /rest/database/:id/ for everything else. Thanks @DjebbZ for helping solidify this idea. Will communicate with the authentication plugin to know if we should allow or deny.

  2. Get the authentication plugin going. This will be an iterative process, as we will need to create an event for when something is unauthorised, and allow the GUI plugin to hook into that event to display a login page or error page appropriately. Allowing the user to actually login.

  3. Develop two gui/admin plugins. The first is contenteditable with Create.js for editing simple documents and properties. The second is a sidebar gui of all the documents, with the location and title. With a search bar powered by Query Engine, and a create new document button. Clicking on a document (or clicking create new document) opens a new sidebar, allowing you to edit the document location, and its file contents using a code editor like ace or codemirror. It will follow metro ui principles and be as simple as possible. If the user is not logged in, then the sidebar will show login information (logged in status retrieved from authentication plugin).

Things worth mentioning:

  • The rest, and gui plugins will all operate on their own ports. The GUI/admin plugins will load in the website into an iframe to avoid conflicts. We can expose which ports are used by adding a meta block like so <meta name="docpad-rest" content="http://url:port"/> etc.

Clone this wiki locally