Clone wiki

webcandy / o_two

History: Release 0.1: the initial merge of StickyNotes with WebMachine.

WebCandy goes RESTFul

Release 0.2 changes:

  1. static and DB requests are served by separate resources.
  2. The supervisor was rolled back to its original, for relative paths are supported, see below for the Dispatch.conf
  3. The StickyNotes application.js was updated to move from the generic POST to
    1. GET for action:read_all,
    2. PUT for action:update
    3. DELETE for action:delete
    4. POST just for action:create
  4. The StickyNotes notes.erl had the read method updated to support common message standard (conversion could be done in the resource as well though)
  5. The home page has admin functionality. It allows you to
    1. check the WebMachine TRACE status
    2. set TRACE ON / OFF (see below)
    3. go view the wmtrace page
    4. Play with HTTP methods and do much of Curl functionality.
    5. Go to the StickyNotes client

The Trace Admin Interface

On top of the home page there are two buttons in the trace group: Refresh and Turn ON (Turn OFF). The refresh will show you the current trace status in the left. How does it work?

The priv/dispatch.conf is:

{["_trace"], webmstn_admin_resource,[]}.
{["notes",note], webmstn_notes_resource,[]}.
{["notes"], webmstn_notes_resource,[]}.
{['*'], webmstn_static_resource,["priv/www"]}.

Trace admin. Logic.

The first config line is used for view the dynamic trace list page or the individual trace results. The second line is administrative. The url is always /_trace

HTTP Methodaction
GETask for trace status

Trace admin. Backend.

When the PUT request comes to /_trace, the webmstn_admin_resource virtually converts the Dispatch.conf to the following:

{["_trace"], webmstn_admin_resource,[{"priv/traces"}]}.
{["notes",note], webmstn_notes_resource,[{trace_dir,"priv/traces"}]}.
{["notes"], webmstn_notes_resource,[{trace_dir,"priv/traces"}]}.
{['*'], webmstn_static_resource,[{trace_dir,"priv/traces"},"priv/www"]}.

Of course, the file is read once and it is only the dispatch list in the RequestData, which is affected. The path to the trace folder, "priv/traces" is given in the first row of the Dispatch.conf, and it simply gets copied into all lines but webmstn_admin_service which does not need to be traced.

The resource code is already prepared to the tracing:

%% webmstn_notes_resource
init([]) -> {ok, #ncontext{}}; %% trace off mode
init([Cfg]) ->                 %% trace on  mode
    {trace_dir,Dir} = Cfg,
	AbsDir =filename:absname(Dir), 

and the webmstn_static_resource as well:

%% webmstn_static_resource
init([DocRoot]) -> {ok, #context{docroot=DocRoot}};
init([Cfg,DocRoot]) -> 
    {trace_dir,Dir} = Cfg,
	AbsDir =filename:absname(Dir), 
	{{trace,AbsDir}, #context{docroot=DocRoot}}.

CRUD Database operations. Server

The original version of StickyNotes has all operations communicating through the POST channel. The code was very short and elegant. The actual operation was parsed by the POST handler process_post and the notes was called for that action. The rest was encoding/decoding of the message body. Just several generic lines of code do all of it in the resource.

Not anymore. We have four different types of message (plus HEAD, which goes the same way as GET) and we need at least four handlers. Now webmstn_notes_resource accepts all methods:

%% webmstn_notes_resource
allowed_methods(RD, Ctx) ->
    {case wrq:path_info(note, RD) of
          undefined         -> ['POST'];        %% for the {["notes"], webmstn_notes_resource,[]}.
          _ -> ['GET', 'HEAD', 'PUT','DELETE']  %% for the {["notes",note], webmstn_notes_resource,[]}.
     RD, Ctx}.

That means you can only POST to /notes to create a new note and use GET/PUT/DELETE /notes/321 to read/update/delete a note 321. One special Id, all is used by GET /notes/all to initialize StickyNotes screen. It merely says "SELECT * FROM NOTES". DELETE/PUT with all are not implemented - just placeholders for now.

Go ahead and try

Download Release 0.2