Foundation data structures

Table of Contents About this page Sites, organizations, groups and users Workspaces, workspace servers and projects Libraries and library servers Custom widgets and custom libraries Libraries, widget collections and widgets Themes To be addressed later

About this page

This page describes the foundation data structures for the Maqetta cloud application that supports multiple users.

Sites, organizations, groups and users

• There are multiple sites, where a 'site' is a server that hosts Maqetta
• Within a given site, there are multiple users, groups and organizations.
  • We already support multiple users (although lots of enhancements needed here)
  • An organization typically would be a company, such as IBM or American Airlines, with the idea that ultimately Maqetta sites would offer secure multi-tenancy and provide server-side bridges to organizational-specific LDAP and maybe sendmail services. Each organization has one or more organization admins.
  • (Down the road) an organization admin can create groups, with one or more group admins. The main purposes of group.
    • Shared configuration settings (e.g., which widgets and themes should be used by a particular collection of users)
    • Access privileges (e.g., only people within group A can view each other's workspaces)

Workspaces, workspace servers and projects

• A workspace server is a web server that can manage Maqetta workspaces.
  • Workspace servers are identified by a simple URL, which points to a server that implements the appropriate Orion file client protocols
    • A workspace server can be the same server that hosts the Maqetta application or can be a remote server
  • There is a built-in simple workspace manager that does simple saves into a Unix file system on the same web server that hosts the Maqetta application (i.e., what we have today)
  • We are likely to offer other built-in workspace managers that support source control systems such as Git and RTC. (We will partner with the Orion project on these built-in workspace managers)
  • The list of workspace servers can be modified by site admins, organization admins, group admins, or individual users.
• Maqetta will support a workspace server configuration file (probably a simple JSON file)
  • Lists the workspace servers (by simple URL) that should be made available to users
• Users can have multiple workspaces
  • Each new user gets a single default workspace for each workspace server attached to his account
  • Down the road, users will probably want us to support the ability for a given user to have multiple workspaces on a particular workspace server, but this is low priority for short-term given that we already support multiple projects. Nevertheless, we should architect our code to allow for this possibility down the road
• Each workspace can have multiple projects (already supported today!)

Libraries and library servers

• A library server is a web server that implements Maqetta's library server protocols and delivers a library package (including associated metadata) that can be "installed" into a user project. (Installation is either copy or a magic symbolic link.)
• A library might contain the following things:
  • Runtime JavaScript (and associated CSS, HTML snippets and images)
    • The runtime JavaScript often will include widgets and themes
  • Widget and theme metadata (see sections on widgets and themes below)
  • Maqetta helper JavaScript
• Maqetta will support a library server configuration file (probably a simple JSON file)
  • Lists the libraries that should be made available to user projects
  • For each library, the library server config file lists:
    • URL of library server
    • Library name and version (e.g., dojo 1.7)
    • Whether this library should be installed by default in new user projects
  • Also includes an library-level Maqetta helper logic as needed by that library
  • Can defined by site admin, organization admin, group admin or user
• Maqetta will support a library metadata file (probably a simple JSON file)
  • Library name and version
  • Lists any library dependencies
    • e.g., jQueryUI dependent on jQuery, custom widget A dependent on Dojo
  • Maqetta helper functions at the library level

Custom widgets and custom libraries

• When a Maqetta user does a "Save As Widget" operation, maqetta creates a single-widget library.
• We will provide documentation that tells users how to manually consolidate custom widgets into a single library (versus one library for each widget)

Libraries, widget collections and widgets

• A particular library can contain one or more widget collections
  • Dijit and dojox.mobile would be different widget collections
  • Each custom widget or custom widget library would represent separate widget collections
  • To find the widget collections within a library package, we look for widget collection metadata files that match a particular pattern (what we now call widgets.json)
  • Each widget collection metadata file indicates what devices it supports ("all", "desktop", "mobile", or specific platforms such as "iPhone")
• Within each "widget collection", we should look for:
  • Theme files (what we currently name *.theme)

Themes

• The *.theme files need to identify:
  • Which JS library and version
  • Which widget collection
  • Which device ("all", "desktop", "mobile", or specific platforms such as "iPhone")

To be addressed later

• Within each library folder, we should look for JavaScript library metadata (a simple JSON file, perhaps foo_lib.json) which identifies each different JavaScript library
  • Library metadata files point to any helper files (usually, JavaScript files). The main theme editor HTML file probably should be listed here, but supplemental HTML for widget collections loaded by dijit.layout.ContentPane (href property) should be associated with the corresponding widget collection.
• Within each JavaScript library, we need to search for:
  • "Widget collection metadata" files (what we now call widgets.json).
  • Right now for Dojo we have one massive widgets.json file. This isn't scalable and manageable for the long haul because Dojo's widgets are decentralized, with various widgets in dojox. and various future widgets in the Dojo package repository. In particular, we should tree Dijit and dojox.mobile as separate widget collections.
  • Each widget collection indicates what devices it supports ("all", "desktop", "mobile", or specific platforms such as "iPhone")
  • Which device ("all", "desktop", "mobile", or specific platforms such as "iPhone")
  • Whether or not it is a "wireframe" theme (i.e., handdrawn look&feel)
• In terms of how this relates to custom widgets, I'm thinking that the "save as widget" action creates a widget collection (i.e., a new folder in ./lib) that happens to contain only a single widget.