Skip to content

Home

Jump to bottom
Brian Maiyo edited this page Mar 13, 2015 · 24 revisions

Table of Contents

  1. Feature List (Current)
  2. Standards
  3. General Programming
  4. Database
  5. PHP Classes
  6. The views
  7. HTML and CSS
  8. Javascript
  9. Github
  10. Tests
  11. Database Model

Feature List (Current)

  1. Authentication and Authorization
  • Login
  • Logout
  1. User Management
  • Create new user
  • View list of existing users
  • View individual user details
  • Update user details
  • Delete user
  • Password management still missing
  1. Patient Records
  • Create new patient
  • View list of existing patients
  • View individual patient details (personal information)
  • Update patient details
  • Delete patient
  1. Lab Sections - Create, Read, Update and Delete
  • Create new lab section
  • View list of existing lab sections
  • View individual lab section details
  • Update lab section details
  • Delete lab section
  1. Test Types
  • Create new test type
  • View list of existing test types
  • View individual test type details
  • Update test type details
  • Delete test type
  1. Measures
  • Create new measure
  • View list of existing measures
  • View individual measure details
  • Update measure details
  • Delete measure
  1. Specimen Types - Create, Read, Update and Delete
  • Create new specimen type
  • View list of existing specimen types
  • View individual specimen type details
  • Update specimen type details
  • Delete specimen type

Back to Top

Standards

General programming

  1. All indices should zero based. e.g. if a <select> element has sequential numeric values these would be from the series 0,1,2,3,...

Back to Top

Database

  1. Naming
  • table names, column names: all lowercase, use underscores to separate words e.g specimen_id, test_type_id
  • names with abbreviations may be treated differently e.g. targetTAT makes more sense
  • better long names that makes sense
  1. Use of appropriate field type e.g. ‘SMALLINT’ instead of ‘STRING’ for age
  2. If a primary key is necessary on a table it should be the first column and should be named 'id'. It should be unsigned.
  3. When this id is referenced in another table (as a foreign key) it should be called 'tablename_id'
  4. Table names are in the plural e.g. specimens instead of specimen
  5. Create a migration file for every new table or change to a table. If necessary add the seed data using a separate file. See the Migrations & Seeding section of the online Laravel guide.

Back to Top ##PHP Classes This applies to Controllers, Models, migration and seeding classes, ...

  1. Class names always begins with uppercase e.g. CreateTestTypeMeasureTable
  2. When combining words every word begins with uppercase. Do not use underscores e.g. SpecimenType as opposed to Specimen_type
  3. Method or Function names begin in lowercase and words join in uppercase e.g. getSpecimenTypes()
  4. Provide descriptive class and function comments before their definitions
  5. Variable names - begin in lowercase. Multiple words should begin in upper case e.g. specimenType
  6. Better long names that makes sense e.g. specimenType instead of speTyp
  7. Soft delete(s) preferable to hard delete(s)

Back to Top ##Laravel views

  1. Using blade templating engine
  2. All html elements in lowercase
  3. Using bootstrap for css

Back to Top ##HTML and CSS

  1. All CSS should be placed in an external stylesheet file (public/css/)
  2. CSS class names should use hyphens when joining words e.g. ‘user-image’
  3. Indent for readability in order of precedence e.g.
  .form-group{}
  .form-group.actions-row{}
      .form-group > label{}
      .form-group .form-control{}
      .form-group .form-pane{}
          .form-group .form-pane label{}
  1. Never use !important;
  2. CSS files should have categorised sections e.g. for user files, for general layout
  3. Use contextual elements such as <strong> and <em> instead of <b> or <i>
  4. Page layout should be done from the CSS file. Do not use &nbsp; for spacing. If done properly there should be no need to use <br> either.
  5. Comments: Include the section name e.g.
 /**
  * forms
  */

Back to Top

Javascript

  1. Using jquery
  2. All javascript code should be in external files (public/js/)

Back to Top

Github

  1. Create an issue for each change you want to make.
  2. Create a branch from the master for the same change. The branch name should be descriptive
  3. Once fixed, create a pull request asking a specific person to review the feature.
  4. Reviewed and approved features should be merged back to the master and the branch deleted.
  5. You can link to a line of code, or a section of code by reading here
  6. There are config files that you want to change but don't want to commit, i.e /app/config/app.php and /app/config/database.php you can prevent yourself from accidentally commiting these files by doing git update-index --assume-unchanged /path/to/file.ext your changes will no longer be tracked. Read more [here] (http://archive.robwilkerson.org/2010/03/02/git-tip-ignore-changes-to-tracked-files/).

Back to Top

Tests

  1. Every feature should have an accompanying test
  2. A feature should pass all tests before it is merged into the master branch

Back to Top

Feature check list

  • Tests for the models and controllers where applicable
  • Adding Access controls where applicable
  • Updating the wiki with relevant info about the feature.

Back to Top

Database Model

BLIS Database Design Documentation Download: PDF PNG MWB

Back to Top

Clone this wiki locally