Changes between Version 9 and Version 10 of IIRS/SolutionDesign

Timestamp:

08/25/13 15:55:49 (3 years ago)

Author:

jim

Comment:

--

IIRS/SolutionDesign

@@ -44 +44 @@
 1. '''Core''' --- a ''module'' that holds all the shared variables, admin, functions, permissions and other logic that will drive all widgets and facilitate the rest of the components.
 1. '''Builder''' -- this is the UI ''module'' that will allow a user (with permission) to chose the type of widget, Context (see below) Purpose and style of a Widget and build an instance. The module will take these options and create a 'Widget Instance' (see below) before generating the themed, styled ''Widget Chrome'' (below) for a user to paste into their website.
-1. '''Chrome''' -- the 'Widget Chrome' is this is the actual HTML and related CSS/JS, built by the ''Widget Builder'' (above), that a user cut/pastes into their site in order to display the widget. It's held on the client site and runs via whatever tech drives it (iFrames to start, web services & backbone maybe one day). The chrome used depends the user's choice of ''Type'' (Full screen, sidebar, button options etc), ''Style'' (css, colours etc - not planned to be editable initially), and ''Framework'' (iFrame for now, later other options might become available).
-1. '''Recipe''' -- When user builds a widget, the relevant context and purpose of the widget will be stored in a Drupal ''entity'' called ''Widget Recipe''. This then allows a user to re-generate the widget at any with different styles/types using this recipe. It also allows a central store of both users and administrators to manage widgets and avoid misuse, and provides a means of recreating any widget in use to provide support and debugging. A '''Widget Recipe'' consists of:
+1. '''Chrome''' (output, concept) -- the 'Widget Chrome' is this is the actual HTML and related CSS/JS, built by the ''Widget Builder'' (above), that a user cut/pastes into their site in order to display the widget. It's held on the client site and runs via whatever tech drives it (iFrames to start, web services & backbone maybe one day). The chrome used depends the user's choice of ''Type'' (Full screen, sidebar, button options etc), ''Style'' (css, colours etc - not planned to be editable initially), and ''Framework'' (iFrame for now, later other options might become available).
+1. '''Recipe''' -- When user builds a widget, the relevant context, workflow and purpose of the widget will be stored in a Drupal ''entity'' called ''Widget Recipe''. This then allows a user to re-generate the widget at any with different styles/types using this recipe. It also allows a central store of both users and administrators to manage widgets and avoid misuse, and provides a means of recreating any widget in use to provide support and debugging. A '''Widget Recipe'' consists of:
   a. '''Target''' -- the entity target(s) for the widget... For now the only 'target' data will be an 'Initiative' node, but this can be anything once the appropriate widget displays and services plugins are built (see below).
-  a. '''Purpose''' -- what the widget is for, e.g. National Directory (this is all we're building for the IIRS), Projects near Initiative, Single Node (e.g. for embedding a single page for an event, initiative or other content), Newsletter signup etc etc. Again, 'National Directory' will be the only purpose for now
+  a. '''Purpose''' -- what the widget is for, e.g. National Directory (this is all we're building for the IIRS), Projects near Initiative, Single Node (e.g. for embedding a single page for an event, initiative or other content), Newsletter signup etc etc. The purpose wraps up a set of Displays (Views onto Services) inside Workflows (see below).
   a. '''Context''' -- the language, country, user (owner) and other background information the widget is to be used for. This data will be auto-selected from the user's account, or from another target depending on purpose.
-1. '''Display'''
+1. '''Display''' -- An actual single pane of UI within the widget, either stand-alone or as part of a Workflow. Each 'Display' (effectively a 'View' in MVC) uses the theme layer to render the data provided by a Service that is set by the Recipie's context, target and purpose. However, in Drupal 7 and for the purposes of the IIRS, the Display (UI) and the Service (data/logic) are often provided together by various modules -- e.g. Drupal core's login form... For example, the 'View list of Initiatives' display will provide show the output of a Drupal view that lists the recent initiatives added
+1. '''Service''' -- are little chunks of functionality that deliver data to a View (see below). They are similar to the 'Controller' plus part of the 'Model' in MVC. Ideally the services map directly to real web services, though for now this is not likely to be needed/possible.  Drupal 8/Symfony makes Services much more powerful however. Examples would be 'List nodes', 'Search nodes', 'View Node', 'Log in', 'Register', 'Add node', 'Edit node', 'Newsletter Signup' etc. In Drupal 7 these are effectively menu callbacks.
+
+Hence most (all?) of the initial view
+
+==== Complete widget example ====
+1. User (from France, in French) has permission to create themselves a 
+
+
+1. '''Workflow''' -- A pu