Functional specifications for the web application called lex-opt (web app): Introduction and overview of the project lex-opt is being built for: initially myself and eventually several others lex-opt is a tool that is deemed needed to assist in my work which is investments management and option trading I manage 9 portfolios and I trade options in these portfolios several times a week Documentation: 1. Functional specifications - this document 2. Programming instructions Development plan - this part also includes general programming instructions The development of the lex-opt project is ambitious - currently it is divided it into 3 phases - but only Phase 1 has been attempted to date. There will eventually be implementation instructions for each of the phases These phases will be sequentially implemented - only Phase 1 part a. has been specified to date Phase 1. a. initial program functionality for two specific functionalities - overview of equities - tabular display of specific information from external sources of chosen NASDAQ & NYSE equities (see further information on displayPage below) - establishment of individual pages for each chosen equity presented in the table (see further information on equityPage below) . * information of each equity will include ticker symbol, equity name, historical data-- to be downloaded and stored in the data Archive (directory "Archives"). * information and current data for relevant options - will be loaded as needed or time determined - option information will be stored historically so that the possibility of patterns may be discovered * information will be in .JSON files - one file for each equity * the files will be named by the ticker symbol and the extension will be .json, e.g. APPL.json b. user interface analysis and modifications for ease of use and data capture - these will be added later as the details will be dependent on the results of the initial program functionality Phase 2. testing & data collection - 2-3 months of applying the application to real activities (still using localhost / Apache2 and the local computer) Phase 3. analysis of data collected and experience in using the system will lead to further functional implementations Main Directory: Ubuntu/var/www/html/lex-opt_4.0 Programming generalities the name of the project will be lex-opt and will eventually be hosted in lex-opt.com lex-opt will be developed and tested on the localhost environment on the local computer - debugging will be achieved by executing the .html files on different browsers (initially Firefox Developer) addressed through the localhost using the Apache2 server - after development and testing and acceptance the files data and program in the main directory Ubuntu/var/www/html/lex-opt_4.0 will be uploaded to my domain LEX-OPT.com. All of these facilities are established and functional both locally and on my web domain server. lex-opt should be scalable, extensible, and responsive 1. no external libraries will be used, needed or included 2. presentation & analysis (will be executed in the client) programming will be in plain vanilla javascript - access routines in PHP 3. formatting will be using SCSS & CSS 4. SCSS and CSS files will be stored in the directory "CSS" 5. javascript files will be stored in the directory "JS" 8. JSON files will be stored in the directory "JSONcache" 9. PHP files will be stored in the directory "PHP" 10. text files will be stored in the directory "textFiles" 11. design instructions are in the directory "documentation" 12. any errors or logical inconsistencies during development should be reported in text format and in a newly created file with the name "developmentError_" + todays date (only year-month-day) 13. any errors or logical inconsistencies during operation should be reported in text format and in a newly created file with the name "operationError_" + todays date (only year-month-day) 14. During development documentation for each function and process should be reported and clear documentation in English should be stored in text files named with the (displayPage, equityPage, formPage) and the extension .text 15. the html main file will be index .html and stored in the main directory lex-opt_4.0 16. aria roles will be added to appropriate html elements when considered useful for documentation and maintenance 17. Backup and recovery instructions will be added as development proceeds 18. security considerations are not vital at this time as it is a personal tool for my work and does not (in this version) require security or accessibility functionality 19. version control will be instigated by copying the contents into new directories, the current directory is lex-opt_4.0 - the next version will be lex-opt_4.1 and then lex-opt_4.2 and so on. Major changes will have versions that are reflected in the directory name such as lex-opt_5.0 20. I will test the components on Firefox / Chrome /Brave on this computer and later safari on the macBook. 21. where possible and when considered appropriate testing of code should be done using common checks for data validity, try-catch blocks, and logging for functional steps. 22. API instructions and keys will be added for the access routines that are needed - these are not specified in this document at present but will be added as development progresses. As well, all interfaces to external data sources will be interfaced through storage - it is not anticipated (at present) that any of the current Pages will need direct access to external data - all data will be stored in the JSONcache directory in .JSON files. 23. Data files will be backed up as data is accumulated - during development that would be an additional complication and will be implemented when operations are actual. this phase 1a. will have 3 functionalities - each functionality will have an independent html page 1. display-page: - the landing page --- main webapp page this will consist of a dynamically constructed table containing a row for each equity: each row will contain brief, current and summary information and current open or watchlisted options information name: display-page.html 2. equity-page: this will be a dynamically constructed dashboard using data from the JSONcache directory and the file of the ticker - an equity page will be built and activated by selecting the ticker row in displayPage - it will include notes and analysis of the individual target equity and current as well as any previous option information name: equity-page.html 3. forms & archiving: these will be accessible from both the displayPage and the equityPage for the addition and deletion of entries forms will be built dynamically from json files and after submission will access remote data and store it locally in JSONcache archive functions will store the data that is accessed each day - after a form submission has activated a return of data - the data will be stored in the JSONcache and the archive Directory structure: The instructions for creating each functionality page will be in the directory: Ubuntu/var/www/html/lex-opt_4.0/documentation/ 1. display-page instructions in the file: displayPage.text 2. equity-page instructions in the file: equityPage.text 3. auxiliary functions - instructions for creating forms & archiving functions in the file: auxilaryFcts.text Fundamental programming instructions: Files: File names will start with a lowercase letter and have functional names appended starting with a Capital letter, e.g.: displayPage.html domReady.js (sub)-Directories: The main directory (lex-opt_4.0) contains 7 sub-directories - names and contents are described in a. to f. below: a. "CSS" directory - the style sheets - in SCSS form - each file will have a underscore as the first letter, such as: _kern.scss - the main.scss file will contain import instructions for all of the scss files, such as: @import "_kern.scss"; @import "_index.scss"; b. "documentation" - contains text files for creating the pages: displayPage.text auxiliary.text equityPage.text c. "examples" directory - contains html files to execute the functionality and testing pages independently - the functionality of displayPage.html & equityPage.html with the auxiliary functions will be tested independently prior to being activated for operation. d. "JS" - contains all of the javascript files e. "JSONcache" directory - contains JSON data files i. JSON files such as: nuData.json - the latest upload ii. archived data - historical data - listed under each the ticker name of the equity wit the extension json files e.g.: APPL.json iii. analytical data - computed results, such as MovAvr200 - 200 day moving average will be in the archived data in a JSON structure (I will produce the JSON structure for analysis) f. "PHP" - contains php files used for file access of data g. "textfiles" - notes and other useful text files Creating the pages: - displayPage - for the basic layout use the instructions in the directory "documentation" and the file: "layout script for landing pages.text". - then use the instructions in the same directory but in the file: script_displayPage.text - equityPage - for the basic layout use the instructions in the directory "documentation" and the file: "layout script for landing pages.text". - then use the instructions in the same directory but in the file: script_equityPage.text - auxiliary functions - will not have a landing page - will contain forms for various functions but called (button select) from the landing pages (displayPage and equityPage) Suggestions for Further Improvement: Version Control Enhancements: While directory-based versioning is sufficient for a personal project, consider using Git for better version control. Git provides features like branching, merging, and commit history, which are invaluable for tracking changes. Automated Testing: While manual testing is mentioned, adding automated testing (e.g., unit tests for JavaScript using Jest or Mocha) would improve reliability and reduce manual effort. Performance Optimization: The file does not explicitly address performance optimization. Consider adding: Minification of CSS/JS files. Caching strategies for JSON data. Lazy loading of assets. API Documentation: While API instructions and keys are mentioned as "to be added," it would be helpful to include a placeholder or template for documenting APIs when they are implemented. Accessibility Testing: While ARIA roles are mentioned, consider adding instructions for testing accessibility compliance (e.g., using tools like Lighthouse or WAVE). Security Practices: Even though security is not a priority for this version, it is good practice to include basic measures, such as: Input validation and sanitization. Avoiding hardcoding sensitive data (e.g., API keys). Using HTTPS for deployment. Data Backup Strategy: While backup is mentioned, consider specifying the frequency and tools for backups (e.g., daily backups using rsync or cloud storage). Deployment Details: Expand on deployment instructions, such as: Setting up Apache2 configurations. Handling SSL certificates for HTTPS. Managing domain DNS settings.