UI Model

Registered by LucyB

This is a very very rough class diagram for the UI, based on the conversation earlier today. The aim is to agree upon a model to be used in designing the database and creating the web-based user interface. See http://lucybridges.co.uk/giantrobot/GiantRobot.png for a quick view.

Updated 27/12/2009 (LB).

Blueprint information

Status:
Not started
Approver:
None
Priority:
Essential
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
milestone icon 0.5

Related branches

Sprints

Whiteboard

Lucy: Thanks again Jon for taking the time to write this. I've updated the class diagram according to your description below and I've added some comments/questions. Can you check that it sounds reasonable and that I've understood you, please? Also, I've just realised that the class diagram is in a C# style. Sorry about this, I promise that if/when I write some code it'll follow PHP conventions.

My (jon-spriggs)'s view is as follows:

The User accesses the system via OpenID (currently, although conventional usernames and passwords could work), where they are encouraged to create a Template or a one-off Event (which presumably can be converted into a Template?).

Lucy: I think that a user should belong to a group. Where a group is something like MFS or SHS. An event or event template can then be created that belongs to the group. This means an event belongs to a group rather than an individual. This makes most sense to me with how I imagine the system to be used. However, each event still has an 'author', so a single user is responsible for that particular event.

A Template is a standard format for an Event, allowing the user to effectively schedule the same Event multiple times, changing only minor details, not the whole Event detail.

Lucy: I'm still not clear about how an Event Template and an Event relate to each other. I'm currently thinking that they should be the same class with a copy() method to make it easy to create a new event object. The UI would be used to display an event and event template differently.

An Event is comprised of a series of Jobs. These jobs are executed by an engine (powered by something like CRONd, scheduled task, etc.)

Each Job has a Created Time, an Updated Time, an Execution Time, an associated Event (which in turn links to the User), a Status (planned, in progress, complete - success, complete failure, cancelled), a Plugin and the Data associated with the Plugin.

Lucy: Agreed. Hopefully, the class diagram reflects this.

The Data required by each plugin is specified in $plugin->get_fields(), and will be an array of fields and what that field provides. For example, see http://bazaar.launchpad.net/~jon-spriggs/giantrobot/trunk/annotate/head%3A/giantrobot/plugins/irc/plugin_irc.php and also http://bazaar.launchpad.net/~jon-spriggs/giantrobot/trunk/annotate/head%3A/giantrobot/plugins/upcoming/plugin_upcoming.php (please note these paths are correct at revision 14, and are likely to change in later revisions). See the terms used - string, integer, boolean, optional. Notice also that in the IRC plugin, one of the fields is an array, which also contains strings. This function may also return a string value (to provide in the UI), however, by defining this here, we block potential for later translations - this is an issue. Maybe the plugin can also contain a translation folder, and each string returned by the $plugin->get_fields() function will actually be an array of translations?

Lucy: $plugin->get_fields() should return an array of lookup strings, which are then resolved to the appropriate translations by the UI (which will know the appropriate locale). Okay, PHP is weird; it seems that get_fields() returns an array of key/value pairs? I'm thinking that the values should be enums if PHP supports this, rather than hardcoded strings. This will prevent typos and may make it easier on the UI side of things. The keys are obviously the lookup strings.

The UI should provide a simple mechanism to provide the engine with it's jobs (presumably by some form of database?) which are then executed by spawning a plugin instance, providing the $plugin->set_data() function with all the data it requires (via the $plugin->_construct() function when creating the plugin or manually), and letting that start the $plugin->connect() process.

Lucy: I guess the 'engine' could be a script of sorts that will search the database Jobs table for the appropriate Jobs to execute (where the execution time is the same as the current time, or similar)?

Each job will be updated by the plugin as to it's status (TRUE or FALSE for Succeeded or Failed) which can then be reviewed by the user checking on it's status as an individual job (also reviewing data passed to the plugin, the time it was created, and modified) or as a whole event (showing the status of the various jobs).

Lucy: I think a job should be responsible for executing a plugin and that the return value given by the execute() method (or an appropriate error, although I don't know what PHP's error handling is like) should be used to indicate success (or otherwise). I don't think that a plugin should know about a job or be able to update a job.

Obviously, I'm not averse to someone telling me this is wrong, so please, update the whiteboard below, prefixed with your initials and then your thoughts.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.