Difference between revisions of "Forms with Images"
Jump to navigation
Jump to search
| (6 intermediate revisions by the same user not shown) | |||
| Line 12: | Line 12: | ||
:# [[ How Dialog Forms Work ]] | :# [[ How Dialog Forms Work ]] | ||
:# [[ Forms with Images ]] | :# [[ Forms with Images ]] | ||
| + | :# [[ Images ]] | ||
| + | :# [[ Bookmarks ]] | ||
== Overview == | == Overview == | ||
| Line 26: | Line 28: | ||
=== Standard Model and Flow=== | === Standard Model and Flow=== | ||
:Here are how the current Models are and how the data flows from the UI to the database and back. It's pretty straightforward and standard between the different topics. | :Here are how the current Models are and how the data flows from the UI to the database and back. It's pretty straightforward and standard between the different topics. | ||
| − | :The image is stored in the database as bytes. The image is easily created, updated, and retrieved. | + | :The image is stored in the database as bytes. The image is easily created, updated, and retrieved. Only one table is affected and the code Model matches the table. |
<div style="display:flex; justify-content:center">[[File:Img-Standard-Model-and-Flow-00.png|1000px|Standard Image Usage]]</div> | <div style="display:flex; justify-content:center">[[File:Img-Standard-Model-and-Flow-00.png|1000px|Standard Image Usage]]</div> | ||
<br/><br/> | <br/><br/> | ||
| − | === Workaround Model and Flow === | + | === Maintenance Queue Flow === |
| − | :Here is how the proposed workaround will work. It's somewhat complex and <b>requires that the image be a loaded media</b>. | + | :This data flow is based on the workaround model and flow that is deprecated but described below. This implementation will require at least 4 database tables but only on the retrieving end. When uploading an image, a backend ETL process will take care of the table record creation. When requesting the image, the tables will have to be associated. |
| + | |||
| + | :This flow of data is safer as creating database table records is left to the backend and not done by the UI. | ||
| + | :This association and flow of data is likely to be utilized in the future as more OSINT is brought in. | ||
| + | |||
| + | ==== Uploading the Image ==== | ||
| + | <div style="display:flex; justify-content:center">[[File:Img-Maintenance-Queue-00.png|1000px|Uploading Media Primary Photo]]</div> | ||
| + | <br/><br/> | ||
| + | |||
| + | ==== Requesting the Image ==== | ||
| + | <div style="display:flex; justify-content:center">[[File:Img-Maintenance-Queue-Relation-00.png|1000px|Requesting the Media Primary Photo]]</div> | ||
| + | <br/><br/> | ||
| + | |||
| + | === (Deprecated) Workaround Model and Flow === | ||
| + | :Here is how the proposed workaround will work. It's somewhat complex and <b>requires that the image be a loaded media</b>. In this implemention, at least 4 database tables will be utilized. | ||
<div style="display:flex; justify-content:center">[[File:Img-Workaround-Model-and-Flow-00.png|1000px|Workaround Image Usage]]</div> | <div style="display:flex; justify-content:center">[[File:Img-Workaround-Model-and-Flow-00.png|1000px|Workaround Image Usage]]</div> | ||
<br/><br/> | <br/><br/> | ||
Latest revision as of 15:30, 1 December 2021
There are a few Dialog Forms that include a picture to help identify the topic in question. A few examples include: Suspect and Investigator.
Contents
UI Guide Menu
Overview
- When adding or editing the following topics, Suspect and Investigator, you can add a picture to help identify the topic. This picture is from the file system, not a loaded media, and can be easily changed the appropriate (Dialog) Form.
- A new request has come in to add a picture to the Media topic. A database migration will be needed to do it properly. A workaround can be done but it'll add a lot of technical debt.
The Two Paths to Loading an Image
- Here are how the data is shaped into a model and flows through the applications. For the most part, the models(code) match the database schemas(tables).
Standard Model and Flow
- Here are how the current Models are and how the data flows from the UI to the database and back. It's pretty straightforward and standard between the different topics.
- The image is stored in the database as bytes. The image is easily created, updated, and retrieved. Only one table is affected and the code Model matches the table.
Maintenance Queue Flow
- This data flow is based on the workaround model and flow that is deprecated but described below. This implementation will require at least 4 database tables but only on the retrieving end. When uploading an image, a backend ETL process will take care of the table record creation. When requesting the image, the tables will have to be associated.
- This flow of data is safer as creating database table records is left to the backend and not done by the UI.
- This association and flow of data is likely to be utilized in the future as more OSINT is brought in.
Uploading the Image
Requesting the Image
(Deprecated) Workaround Model and Flow
- Here is how the proposed workaround will work. It's somewhat complex and requires that the image be a loaded media. In this implemention, at least 4 database tables will be utilized.
