Migration issues

From PKP Wiki
Revision as of 20:35, 24 August 2010 by Jerico.dev (Talk | contribs) (Splitting new URL changes into two separate topics (workflow + dashboard))

Jump to: navigation, search

To help integrate the new features of OMP into our other applications, we'll describe in this document how we've modified OMP to make it easier in the future to backport.

Every change should be accompanied by the following information:

  • Link to the original BugZilla entry
  • Link to an exemplary migration example patch (within BugZilla)
  • A rough estimate of the number of instances that have to be migrated across all apps
  • A rough estimate of the time required to migrate one instance

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.
  • The original BugZilla entry is http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=4934
  • A sample migration patches can be found here:
  • There are currently 400 files which have non-migrated instances of 'Request::'.
  • The migration of one file should take between 5 minutes and 15 minutes per instance, depending on the number of occurrences.
  • This means that the overall migration effort should be roughly 60 hours.

Replacing HandlerValidators with AuthorizationPolicies (Florian)

  • For a rationale why we replaced handler validators with authorization policies see our [Authorization Framework] design document.
  • The original BugZilla entry is http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=5540 which also contains a sample migration patch.
  • 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)

Changes for OMP: [1]

  • 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.

Changes for PKP-lib: [2]

  • 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
  • Autosuggest selection (Like drop-down list selection, but typically for larger data sets such as users)--See /controllers/listbuilder/MastheadMembershipListbuilderHandler.inc.php
  • original bug reports: tbd.
  • sample migration patches: tbd.
  • migration effort: tbd.

Form Builder Vocabulary (Tyler)

See: Form Builder Vocabulary

  • original bug reports: tbd.
  • sample migration patches: tbd.
  • migration effort: tbd.

Introduction of User Groups (Juan, Florian)

  • change in the data model
  • introduction of "acting as user group" in the session

Introduction of a different (non-role-based) URL scheme for the editorial workflow (Juan)

  • description: Rather than using role based URLs for the editorial workflow we'll have a /workflow URL the content of which will change depending on the "acting-as" user group.
  • original bug report(s): tbd
  • sample patch: tbd
  • migration effort: tbd

Introduction of a dashboard for users (Juan, Florian)

  • description: We'll introduce a common entry point for users. Among other things this contains a submission list which will be common to all roles and change depending on the "acting-as" user group.
  • original bug report(s): http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=5807
  • sample patch: This is a large change with an individual change set per application. Therefore a sample patch cannot be provided.
  • migration effort: tbd.