Page History

...

This guide begins with the back end of SWEET, most of which can be found in org.eagle-i.datatools (the eagle-i-datatools-common module). The backend components are held in common by all of the datatools; they are not specific to the SWEET. The SweetServlet (org.eaglei.ui.gwt.sweet; in the datatools.sweet.gwt package), in this context, is the user-facing endpoint for the data tools backend.

...

Datatools backends (particularly for SWEET and etlETL) need to know the URL of the repository to point to. Because eagle-i applications use https, it's not possible to point to localhost. Instead, the repository location is specified in a configuration file.An example file is found in eagle-i/examples.

...

The repository provides a mechanism for controlling which users can edit which resources. Details can be found in the Repository Workflow Design Guide. It has four core notions: ownership, workflow state, transitions between states, and roles assigned to users (or types of users), which determine which transitions are legal for each user type. All workflow privileges are based on the URI of the user in the repository; therefore, all datatools operations (listing resources, editing them, making workflow transitions, etc.) require a repository username and password.

...

A list of transitions can be found at  at url of a machine with an eagle-i repository]/repository/workflow/transitions.

The repository returns only a list of the transitions that are allowed for the current user, based on the user's role in the repository. (User roles are also configurable in the repository, and again, the repository has a default set of roles with permissions. These are largely beyond the scope of this document.) For historical reasons, the transition query returns with a boolean indicating whether it is legal for the current user; in practice, a user will only see transitions they're allowed to perform.unmigrated-wiki-markup

In the SWEET, these transitions are represented by {{org.eaglei.ui.gwt.WorkFlowTransition}}. These transitions \ [will be\] loaded from the repository, as are the states. The {{PrivilegesInfoProvider}} is responsible for this loading and managing.

In order to prevent conflicting edits, each resource can only be edited by a single "owner". In order to edit a resource, a user must first claim the resource. The user is then set as the resource's workflow owner in the repository. No one else can claim the resource until it has been shared, either explicitly via the "share" button, or by a workflow transition. All workflow transitions clear existing ownership.

...

Many operations require information from the application and domain ontologies. Making that information available is the role of the JenaEIOntModel (eagle-i-model-jena: org.eaglei.model.jena) at the back end. The front-end equivalent is the ModelServlet (eagle-i-common-ui-model-gwt: org.eaglei.model.gwt.server). The details of the servlet and the JenaEIOntModel are beyond the scope of this document. For the purposes of datatools and SWEET, all information about the ontologies is encapsulated in these classes.

Getting data of various kinds (AbstractRepositoryProvider and its subclasses)

In order to allow a user to enter and edit data, SWEET must retrieve data in various forms from the ontology and repository. The relevant interfaces are found in org.eaglei.datatools.provider, and implementations in org.eaglei.datatools.jena.

...

MainController

The MainController uses the {{Mode (an enum from QueryTokenObject) from the ApplicationState to determine what belongs in the main area of the window. Whenever the application state updates, the MainController checks first for a valid user (if there's none, it clears everything), and then checks the mode.

...

• EDIT: edit a single resource; show the edit form (including all possible properties as supplied by the domain ontology)
• VIEW: shows all the properties of a single resource, but only those that have been annotated by a user. In other words, all the *actual* properties (including the properties not shown in search) but not the *potential *  properties shown in EDIT mode.

...

• LIST: list all resources meeting the criteria (including the filter criteria) from the ApplicationState. If a typeEntity exists, show only resources with that as a base type (otherwise, show all resources). If a providerEntity exists, show only resources belonging to that lab (or other resource provider). The ApplicationState is set to this mode by the LeftListGridRowWidget, or after a resource has been deleted.
• FILTER: the ApplicationState mode used when the user clicks the "go" button in the FilterPanel. Shows only resources meeting the description from the ApplicationState, further refined by the FilterPanel options (resources belonging to a subclass, only resources in Draft mode, etc).
• RESOURCES: a (hackish) way to get an empty resources grid shown. In highly-populated repositories, trying to show all resources of all types from all labs is prohibitively slow. Resources mode short-circuits the process.
• REFERENCES: List all the resources that refer to the instanceEntity from the ApplicationState. Resource A refers to resource B if resource B is the value of a some property on resource A. (In rdf-speak, we're looking for all the subjects A where B is the predicate for some statement about A, and A is an instance of one of the types we consider as eagle-i resources.)
• STUBS: List all the resources that were created through a "create new" mechanism in the edit form.
• Wiki Markup_PROVIDERS_: Shows a list of all organizations to which resources can or should be added. \ [Note: currently broken--shows all organizations\]
• MYRESOURCES: Show exactly the resources for which the current user is the editor/has claimed the resource.

...

For any mode in the listing resources group, the MainController retrieves a list of EIInstanceMinimals, and then draws a ResourcesGrid. The ResourcesGrid is responsible for drawing lists of resources, of whatever sort. The ResourcesGrid has a FilterPanel at the top, which allows filtering the list by any combination of subtype, current owner (claimed by user, or all), and workflow state. It also has two PaginationWidgets (one at the top and one at the bottom), which determine how many resources to show per page and which page to view.Note that no total counts are available (and page sizes may be slightly off) because a single resource may be returned multiple times from the repository, but is filtered out at the front end.

The ResourcesGrid displays a list of {{GridRowWidget, each of which wraps an EIInstanceMinimal.The GridRowWidget displays relevant information from the EIInstanceMinimal, and provides links to allow the user to claim or share the resource (if it's in a workflow state that the user can change), and to edit or delete it once it's been claimed. The GridRowWidget also has a checkbox which interacts with the ResourcesGrid's actions drop-down to allow bulk workflow transitions.

...

Panels for editing and viewing single resources are constructed by the FormsPanelFactory, which is responsible for fetching the instance (or getting a new, empty instance) and constructing a DatatoolsInstancePanel to display it.

Much of the instance display logic is shared with the eagle-i search applications, so the base Renderer interface, the abstract OntologyPropertiesRenderer, and the abstract InstancePanel are all found in org.eaglei.ui.gwt.instance.

...

The OntologyPropEditRenderer is the ontology renderer for editing resources in a datatools context. Since it needs to present all possible properties, it loads the properties from the EIOntModel as well as the values that currently exist on the instance (if any). The OntologyPropEditRenderer draws widgets that are subclasses of EditWidget (usually wrapped in EditWidgetCollections).

EditWidget and EditWidgetCollection

As previously mentioned, the values for a given property of an EIInstance is (generally) a set of values (collection that is unordered and for which each value must be unique). As a result, when the user changes a value using an edit form, there needs to be a mechanism for tracking which value is being replaced.The EditWidget heirarchy hierarchy performs that function.

The base EditWidget class holds a reference to the EIInstance it is editing, the EIProperty for which it is the widget, and, crucially, an oldValue field. Since properties can be either objects (EIURI}}s) or data types (strings, booleans, dates, etc), the {{oldValue is a string; if the property is an object property, the subclass must use getOldEIURI value to get the correct oldValue.

...