Peditor Overview

A highly extendable application to abstract and visualize the edit procedure of common web pages. Combine the two words Page and Editor, we get the project's name Peditor | 'peditə |. Another goal of Peditor is make it easier to create plugin(widget) for it.

Project home: Github

Roadmap

Following development will focus on:

• Write some more userful widgets for demo.
• Make the widget system api richer and more robust.
• A multi-user backend system to support the management of pdoc.
• Make the whole system easier to plug into a CMS, which means more api to interact with the backend system.

Build & Control

• Requirement

  • Unix-like system.
  • ZSH v4.0+ installed.
  • CouchDB 1.3.0+ installed
  • Node.js v0.10.0+ installed.

• Configuration

  The global options in the config.json file.

  port	The server port.
  debug_port	Debuger listener port
  db_port	Database port
  mode	The default mode is development mode.

• Build

  1. Install node dependencies:

     npm install --production

  2. Init the database:

     npm run-script db

  3. Install client app dependencies:

     npm run-script client

• Control

  • Start server:

    npm start

  • Restart server:

    npm restart

  • Stop server:

    npm stop

  • Launch server in background:

    npm run-script launch

Test & Debug

• Make it easier to access the tools in the 'node_modules'.

  source kit/shell_evn.sh

• Install dev dependencies:

  npm install

• Watch and auto compile files:

  npm run-script watch

• Auto test:

  npm test

Tech

The knowledge required to develop this project.

Frameworks	Linux, CouchDB, Node
Libraries	Express.js, Underscore.js, jQuery, Bootstrap
Manager	npm, bower, grunt
Languages	Coffeescript, Javascript, html, stylus, css

The knowledge required to create widget.

Libraries	jQuery
Languages	Coffeescript, html, css

MSV Architecture

Here I introduce a new web app architecture that I created, MSV. For more information about the MSV, read this article.

Compared with the famous MVC, there is no controller component, instead the service component will take the charge.

The biggest disadvantage of this architecture is that it heavily depends on js and ajax. But it brings back better response performance and smoother user experience.

Client App

1. Peditor Layout Mode

   There are two types of layout mode, Outlone and Preview.

   Outline Mode

   To make it easy to see the relationship between containers.

   

2. Flexible Height Grid System

   All containers are created by 'drag and drop'. Now there're four types of containers:

   • root
   • row
   • column
   • widget
   
   • The root can't directly hold a column.
   • A row and a column can't become sibling nodes.
   • All containers except the widget can has height constraint.
   • Only column can contain widget. A column can remain empty, or has several widgets inside, which behaves like a Stack List.
   • A row's width can be an absolute value, but a column's width is always a relate value of its parent node.

3. Widget Scaffolding

   You can visit http://localhost:port/widgets/your_widget_name to debug your created widget.

4. Property Editor

   Here's the properties that editable for each container.

   Root	background image, width
   Row	background image
   Column	background image
   Widget	Implemented by widget itself.

5. Save & Load Manager.

   This will create a unique link of current pdoc.

6. History control

   Works the same as a common editor.

Protocol

• Widget API

  Here a simple overview of the widget api.

  • Every widget should be placed into the client/widgets/ folder.
  • All assets of a widget should be placed into a folder, and the folder's name should be the widget's name.
  • The entrance file of a widget should be index.html, and it should be directly under the widget's root folder.
  • All widget's js and css should be declared under the namespace of PDT, the abbrev of peditor.
  • There's a /client/widgets/template/index.html you should read for more details information about the api.
  • There's a /client/widgets/title/. It is a basic example of how to use the api.

• Page Document

  A file for saving the edit's states. I call the format Page Document, file extension '.pdoc'. It saves the edit commands and page resources. The pdoc is based on json, and utf-8 encoded. Here's the overview of its fields.

  _id	A unique id of the pdoc.
  _rev	The unique revision id of the pdoc.
  mime	The file's MIME information. Default value is 'text/pdoc+json'.
  doc	The html that represents the current page state.
  scripts	The js and css that the page requirs.

Server App

The CouchDB is good enough, it has already covered most the requirements with its build-in functions.

1. Page documents manager, CRUD.

Lisense

BSD-2-Clause

Sep 2013 ys