Skip to content

Development Notes

David J. Davis edited this page Aug 6, 2020 · 11 revisions

This page is designed to be a catch all for development notes, but could be expanded if it starts to get too large. The concept is to make notes on things that may be different in the development of MFCS so that these changes can be noted for other aspects of development.

TABLE OF CONTENTS

STACK CHANGES

OLD BACKEND STACK

  • PHP (custom framework), MYSQL, Linux Libraries and Compiled Libraries (leptonica, tesseract, imagemagick, ffmpeg, and more)

OLD FRONTEND STACK

  • PHP, HTML, CSS, JQuery, and Various JS Libraries including (lodash, select2, ckeditor, jquery, jquery ui, bootstrap, and more)

NEW BACKEND STACK

  • Ruby / Rails, Postgres, Docker

NEW FRONTEND STACK

  • Webpack, Stimulus JS, Bootstrap (some of these may be reduced in the future)

DATABASE STRUCTURES

  • For now most database structures are staying the same, except the json items are being stored as json b and should be able to be indexed for search needs. Using postgres will allow us to keep things from being serialized in the database and allow us to read them as needed.

FIELD BUILDER

Field names have changed to provide better readability or work with stimulus libraries.

  • All field names have gone to snake case instead of camel case.
  • some fields have been prepended or made more verbose to allow for better code readability.
  • Drag and Drop Libraries have been removed in favor of building one with Stimulus and making more accessible options.
  • Extraneous unused items have been removed
    • Fieldsets
    • Validation based Text Fields (Email, Phone, Website, etc) Removed in favor of text with added validation

The process of making fields and applying json values has been changed from nested inputs to data-attributes that hold json strings for clarity since that is how the fields will be pushed through the backend. They are then parsed and concatenated for saving.

IDNO

  • idno confirm has been removed, currently it was attached to all idno fields, but never used and had no way of being modified. I assume the idea was to use a confirmation pop up to ensure that users wanted to use that IDNO as it is not supposed to change.

All Fields

  • Removed access as a term in all field hashes because the previous code simply checks that it exists and is empty, so it is really do nothing. If it was used to validate the json then then there are other ways to verify that would be better than a set and empty item.
  • Fieldsets have been removed as they are not necessary in future developments and are currently not being used.

DISPLAYING FIELD BUILDER FIELDS

This section has been reduced to a separate presenter view to avoid having to duplicate efforts in each page and using javascript. The items will have data attributes that control any javascript logic making them usable in any form that the attribute makes an appearance.

The difference is that this also then allows the form to be viewed showing all sub-logical fields in a single page for review.

JAVASCRIPT

Much of the JavaScript is changed completely to rely on Stimulus JS which relies on mutation observers to accomplish similar tasks.

TESTING

There will be tests for all parts of the application (not 100% done currently, but all ruby and some javascript instances are all tested) BDD integration tests still need to be done.

Validations Modifications

In the validations classes that come from MFCS the following changes have been made and tested in the new version of MFCS.

  • URL String Validation was remade and tested using a regular expression. The current regular expression didn't account for all types of URLS.
  • Optional URL Validation was changed form a conditional with multiple regular expressions to allow for blank entries or pointing back tot he original URL.
  • IP Addresses have been changed from a broken REGEX to a built in library to the Ruby Core language. If the object doesn't instantiate then it is improper IP address.
  • Integers have been changed to using the Ruby Core Integer class, if it doesn't instantiate an error is thrown and it rescues to return false.
  • Alphanumerical limitation validations have all been modified and tested to a variety of edge cases to ensure that they are 100% working.
  • Date classes have been modified to use the EDTF date strings and will not validate if not a proper EDTF date.

Naming Conventions Changes

  • In the old version of MFCS "objects" referred to the data columns where the metadata records, and digital object records were saved in the database. In the Ruby programming language Object is a base class and a protected keyword. The new MFCS will refer to "objects" as "items" and they will be used for the same things as the previous MFCS.