Web Spinners

A web spinner is a server side agent that interprets WBOL documents and outputs HTML fragments and documents. But technically, just as well, PDF.

Technology

Spin the Web is built on the following technologies: HTML, SVG, CSS, Javascript, AJAX, JSON and XML. Although a web spinner can be developed in any programming language Spin the Web has chosen Javascript and technically its only prerequisite is a system running Node.js.

Web spinner logic

A web spinner responds to REST requests generating, for the most part, HTML documents and fragments: the URL points to a resource that will be interpreted either as a page or a content, see the REST section below. When a page is requested, the included contents may be either rendered contextually or requested asynchronously by the client once it has loaded the page—this same mechanism can be used by the client to poll contents periodically.

REST

A web spinners responds to REST requests interpreting the URL as follows:

host
the spinner redirects to the home page
host(/area)+
the spinner redirects to the area main page
host(/area)*/page
the spinner acts on the page if it is visible in the requesting context (see Security) else redirects to the home page
host(/area)*/page/content
the spinner acts on the content if it is visible in the requesting context (see Security) else nothing is returned

REST deals with contents and pages. For example, the URL //www.acme.com/production/orders may point to the /production/orders area in which case the associated main page is rendered, or orders may be a page in the /production area whaterver it is, it is clearly specified in the WBOL document.

GET, POST, PUT and DELETE

Text Preprocessor

Data requested ...

Layout API

Row and field cursors

Contents are focused on data, data represented as tuples; the content cycles through tuples while the layout API through the elements, an element may be a tuple itself, the object symbol o() ...

Security

WBOL security model is based on group visibility.

  1. A webbase can have any number of groups: guests, administrators, developers, webmasters, translators and users are built-in.
  2. A webbase can have any number of users: administrator and guest are built-in.
  3. Each user belongs to one or more groups, by default, all users belong to the guests group with the exception of the built-in administrator that belongs to the administrators group.
  4. Each content, page, area and site has an associated visibility control list (VCL): a table containing visibilities control entries (VCEs) that specify whether a group can view or not the associated element.
  5. The visibility in a VCE is either true, false or undefined in which case the parent element VCL is inherited.
  6. A single true VCE in an element VCL is necessary for the element to be visible.
  7. By default the only visible page is the home page.
  8. By default all contents in a page that is visible are visible.
  9. The visibility of a content is dependent on the visibility of its parent page and only if it is true the content VCL is considered.
  10. The visibility of pages and contents is overridable programmatically via the visibility attribute.

The visibility concept is exploited togheter with the sequence of contents...

TODO: securing data and securing data management

Extensibility

Creation of new contents...