Introduction of Routers (Florian)

The request class contained methods like getRequestedPage() and getRequestedOperation() which were specific to page request and not compatible with AJAX or more generally sub-component requests.

We therefore introduced a distinction between the request containing URL and request parameters and routers that pass control to a handler operation based on the request information.

A dispatcher is now responsible to choose an appropriate router for the request and let it route the request to a handler endpoint.

We also want to reduce the number of static function calls which have been very frequent in connection with the Request class (advantages: enable inheritance, compatibility problems, design advantages). We now pass a request object along the execution chain, passing by the dispatcher and the router into the handler operation. All handler operations now receive the request as a second argument to their method call.

All instances of HandlerValidators have already been replaced there are however still a large number of validate() methods that contain custom authorization code which must be converted into AuthorizationPolicies.

There are currently about 70 instances of the validate() method.

There are still compatibility classes for the deprecated HandlerValidator classes which must be removed.

The migration of one method takes about 10 to 15 minutes, if a new policy must be written first (which will occur quite rarely once the first few files have been migrated) then we have to count another 15 minutes per policy. Removing the legacy handler validators takes not more than 10 minutes.

The overall migration effort therefore should be roughly 15-20 hours.

Layout overhaul (Brent, Juan, Matt)

Various locale keys have been added for navigation text (see the changes in the github commit)

Added 'Select Role' and 'Select Press' block plugins

Added omp/styles/omp.css file which contains references to all CSS files used. This file is the only CSS file needed to be referenced in omp/templates/common/header.tpl. The existing CSS files have been modified (see the changes on github)

All javascript is being called in /templates/common/header.tpl. This means that the jQuery plugin is no longer in use. In the future we will be using Google's CDN to call jQuery and jQueryUI, and eventually other libraries.

New container divs have been added to header.tpl, and leftSidebar/rightSidebar code has been removed. (see the changes on github for exactly what to change)

A new breadcrumb file has been added in omp/templates/common/breadcrumbs.tpl--This should be able to be copied directly over (or eventually abstracted into pkp-lib)

/omp/templates/common/footer.tpl was added to include closing tags for new divs added to header.tpl. When all of the application's UIs are in sync, this can be abstracted to pkp-lib.

Various CSS and Javascript libraries have been added to allow for new UI features, as well as new images

original bug reports: tbd.

sample migration patches: tbd.

migration effort: tbd.

Listbuilders (Matt)

For form elements that involve simple manipulation of lists (like masthead user lists in all apps), the MVC structure of modifying this data can be compacted into a listbuilder handler located in controllers/listbuilder/. There are three source data types of listbuilders that can be used, here are some examples:

Free-text entry (for adding new data to the system)--See /controllers/listbuilder/AuthorRolesListbuilderHandler.inc.php

Drop-down list selection (for adding already-existing data to a new group or classification)--See /controllers/listbuilder/InternalReviewRolesListbuilderHandler.inc.php