Changes between Version 10 and Version 11 of IIRS/SolutionDesign

Timestamp:

08/25/13 16:51:46 (3 years ago)

Author:

jim

Comment:

--

IIRS/SolutionDesign

@@ -32 +32 @@
 1. '''Transition Network Core''' - D7 - variables in feature wrapping all shared dependencies and extras needed to make the site(s) tick.
 1. '''Transition Initiatives''' - D7 - a feature wrapping up a content type, some simple list-style views (user-facing and admin) and panels panes.
-1. '''Transition Initiatives Widget''' - D7 - a module providing the widget (converted from the [https://wiki.transitionnetwork.org/Sharing_Engine D6 PSE project]).
 1. '''Transition Hub ''' - D6 & D7 - anything specific to national hubs goes here. Each 'Hub' content represents a national hub and has language(s), name, country, website and other data. D6 version provides content type, plus 'country homepage' with translated text and widget embedded panels view. D7 provides content type (and others feature TBC).
 1. '''Transition Users''' - D7 - a feature wrapping up a basic user account, plus some views (users-facing and admin). Need to decide if this is core D7 accounts, or needs Profile2 etc. Ideally would handle social login/register too.
@@ -38 +37 @@
 1. '''Transition Network Sync''' - D6 & D7 - a module that uses pluggable services (in the above point; for initiatives, users, projects, hubs etc etc) to sync data back to the 'hub' D6 TN.org site.
 
-=== Widget-related custom modules ===
+=== Widget design ===
 The widget is to be a more flexible evolution of the work started in [[Sharing_Engine/Technical_Proposal Project Sharing Engine]]. The plan is to build on this base but turn the it into a clear, clean model based on a set of components that can be added, extended and re-used. Since Drupal 7 is not MVC, and neither is Drupal 8, the proposal is to use the CTools Plugin architecture ([http://ygerasimov.com/ctools-plugins-system example here]) to allow new Widget components to be added/enabled over time.
 
+==== Widget modules ====
+1. '''Transition Initiatives Widget''' - D7 - a module providing the widget (converted from the [https://wiki.transitionnetwork.org/Sharing_Engine D6 PSE project]).
+1. '''Widget 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. '''Widget 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 Recipe' (see Components, below) before generating the themed, styled ''Widget Chrome'' (below) for a user to paste into their website.
+
 ==== Widget components ====
-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''' (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. '''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 
 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. '''Style''' -- How it will look when the Chrome is built; Options ''Type'' (Full screen, sidebar, button options etc), ''Style'' (css, colours etc - not planned to be editable initially), and ''Delivery Framework'' (iFrame for now, later other options might become available).
+  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. '''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. 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''' -- 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.
+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 Recipe'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. [NOTE SURE ABOUT THESE with regards to ''Displays'' -- TBC] '''Service''' -- are little chunks of functionality that deliver data to a View (see below). Ideally the services map directly to real web services, though for now this is not likely to be needed/possible since Drupal provides services and displays together. 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 with extra theming. Drupal 8/Symfony makes Services much more powerful however
+1. '''Workflow''' -- A set of displays that go in sequence. E.g. Login/Register -> Add [Target] -> Thank you page.
 
-Hence most (all?) of the initial view
+==== Widget Builder example ====
+1. National Hub user (from France, in French) has permission to create themselves a widget.
+1. They go to the Widget Builder and choose the ''Widget Recipe'' they want:
+  * Purpose: "National Hub Listings"
+  * Target: "Initiatives"
+  * Style: "Full page", "Standard theme", "iFrame"
+  * Title: (auto-generated but editable) t('Initiatives National Hub Listings, full page') = "Initiatives Listes nationales de Hub, complète la page".
+1. They click 'Save & Generate' and their ''Widget Recipe'' entity is saved, and the context is automatically added:
+  * Country: "France" (FR)
+  * Language: "Français‎" (fr)
+  * Owner: [current user]
+  * Status: "Active"
+  * Created/Edited: [date/time today]
+1. The page refreshes and their widget is shown in the example area, plus the Chrome (HTML code) in a box to copy/paste.
 
-==== Complete widget example ====
-1. User (from France, in French) has permission to create themselves a 
+==== Widget Plugins needed ====
+Leveraging CTools, the following plugins are needed for the IIRS:
+* Style plugins:
+  * Types: "Full page", "Sidebar", "Button only" = Chrome styles we currently have.
+  * Style: "Default" = whatever we come up with based on very simple style.
+  * Delivery Framework: "IFrame" = shows displays and popups using HTML IFrames.
+* Purpose plugin: "National Directory (recent)" which uses:
+* Target plugin: "Initiatives" = Provides services for and entity handling for viewing/adding Initiative Nodes.
+* Display plugins:
+  * "Tabbed National" = Large display with tabs for 'Recent', 'Map', and 'Search'). Uses following displays "Recent Content Listing", "Content Map" and "Content Search". Includes 'help' and 'about' links.
+  * "Simple National" = Small display with tabs for 'Recent' [target] nodes. Uses following displays only the "Recent Content Listing" displays. Includes 'help' and 'about' links.
+  * "Recent Content Listing" = A list of recently added [target] (initiatives in our case) in [country]. 
+  * "Content Map" = A map of recently added [target] (initiatives in our case) in [country]. 
+  * "Content Search" = A way of searching for [target] by name and location.
+  * "View Content" = A popup to display a single [target] Node. Can also show edit options if user has permission. Used for displaying both the Initiative details, and the 'About' and 'Help' pages.
+  * "Log in/Register" = A unified Login/Register form display with Social Media connect options.
+  * "Create Content" = A form to create [target] content, showing only core/required fields).
+* Workflow plugin: "Registered User Create Content" which takes a user though the displays "Log in/Register" -> "Create Content" (for Initiative target) -> "View Content" ('About' page for Initiative target).
 
-
-1. '''Workflow''' -- A pu
-
+=== To do (updated 25 Aug 2013) ===
+* Pin down relationships between views (both Drupal Views and View per MVC), Displays, Workflows and Services. It's ''almost'' clear but until development is started and the abilities of CTools are known, this is not easy to fully document at this stage.
+* Work out how the 'Target' plugins will provide access to nodes, and what if anything they do to displays and services... Ideally they should extend such displays and make available certain fields that are important (e.g. location for initiatives/projects/events, date for events, type for resources etc).