Migration issues

From PKP Wiki
Revision as of 07:59, 9 July 2010 by Jerico.dev (Talk | contribs)

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

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


Layout overhaul

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

Listbuilders

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

Form Builder Vocabulary

See: Form Builder Vocabulary