Introduction#
Powerforce is a workforce management application written on the Windows platform. The application is written on the back of a toolset from Revelation Software (US).
It comprises a development environment and its own database structure, where the development environment (I think) is akin to Visual Basic version 6 (in terms of the widgets available), the language is basic - what I'd refer to as Dartmouth Basic (not Microsoft VB). The database itself is best described as NOSQL and always has been. We have the concept of field delimeters to seperate data table fields. The language supports the structure.
What's wrong with OI#
This article best describes the short-comings of this environment looking forward
Big Picture#
The big picture is that I need to move into the 21st century sooner than later. I am looking at AWS Appstream as a means to extend the shelf life of the current Windows 32 bit platform. However, this is a stop gap, we must move to a new mind set.
The mind set of architecture platform that I have selected is a RoR REST backend application, and Ember on the browser. In respect of the few things that we need for mobile (phone), we will likely utilise React Native, until I source a means to use Ember Mobile (??).
The Rails mindset most closely resembles the current environment that I develop in, notwithstanding some poetic licence in terms of things such as object based development, etc. The database (noSQL) is a mindset that we've always had, so other than learning new syntaxes for whatever platform i choose. At this stage i am looking towards mongo and couchbase. Couchbase because the product environment (I'll call OI) has some inbuilt support for, in that I can program to couchbase directly as if i were speaking to the internal database.
There are a number of tables that we are likely to deploy to MSSQL, perhaps Postgres as some stage depending on how competent we become. The goal is to put these databases behind a RoR REST interface purely for CRUD operations, and then refactor our code to make local http calls vs coding such as 'READ, WRITE' to/from fileUnit.
Prototyping the move to web#
I have made the decision to use emberJS as the web platform, because we have previously used sproutcore for our first attempt at a web interface for some web-facing interface that needed to be developed. I also have respect for Jahuda from his JQuery and Rails days. Whilst still struggling to write a 'hello world' app in Ember, i see its many benefits as a valid choice for moving forward
What i want to do is to prototype and start to think about how a re-write of our application needs to proceed. And, it seems that my years of procrastination might be aligning with the likes of web component development and hopefully if designed correctly and approached methodically, i can do more with less. In my study of our own application i have tried to understand and focus on what each individual 'widget' (input field in the current Win environment) does, and how many unique widgets we actually have. Happily the truth is, not many. We have very basic data input requirements and so i am looking to find a good start on the correct (best fit for my needs) web component approach (happy to go glimmer, if i can get to understand it quickly enough)
1 the 'key' field to table, usually with some search functionality. The down-arrow indicates search field 2 simple text input no validation 3 textfield, no validation, free form (in this instance data entry) 4 this field intentionally left out 5 lots of tabs (open for review in terms of how to map this across to a web interface) 6 buttons that sometimes kick of other modal windows 7 grid, with the possibility that the 'Role' column might be dropdown data 8 picture field 9 date fields - where there is some manner of validation (eg employment date must be in the past, DOB, must be such that it's greater than 16 years ago (we don't employ kids, as an example validation)
This is another example of a busy form, not all forms are as busy. However, these fields are indicative of the sample of data inputs that we need to cater for.
This link leads to other similar sample of screen shots of our application when we first started with sproutcore.