Hi @psoas @raroldan17
I have been giving this some thought and have some insights Iâd like to share.
While I am one of LBFâs biggest fan, we are finding it more difficult to expand Demographics with one to many type relationship inputs. One hold back is that demographics is hard wired to the patient_data table which over time has expanded greatly. What is needed is the ability in LBF Groups to define what the primary table for storage will be for the groups content. So diverging away from the patient_data table is just a first step.
Next is dealing with a more complicated form than just collecting data in static fields where over time the screen will become tiresome to view. In the case of additional addresses then four or five static fields times say three address datasets makes for rapidly expanding lost of screen space. So the natural pattern is to slide/popup the addition data which is fine however, LBF doesnât currently have that mechanism.
This is where Iâd purpose adding additional data types for handling sub forms or templates. The template could be another LBF with itâs own groups/sub groups where tables are defined or a custom HTML form called as a plug in. In this case the HTML plug in can handle the data distribution to storage. I also wouldnât rule out using twig templates so data types would need to consider this as well. Remember that LBF groups can have sub groups. For example:
This would mean developing data types with pointer to templates and a display type(slide/dialog).
The data type and supporting items could be something like:
- data type: pop_template title Additional Addresses
- List would be a list created in Lists for template by LBF name or path to HTML template.
There are numerous examples of using dialogs(dlgopen) throughout core. Dialogâs can be called as iframes, passed in content or fetched content via ajax. Dialogs can also return a promise for several events(all the normal modal events plus) which is how I recommend using or at least allowing for when implemented as promises become very useful in many form sceneries.
To manage on the backend Iâd recommend we create a new controller class and start migrating the procedural parser code(options.inc) to methods in a new service class or several. There are several ways to go about this but my first thought is an abstract class that could/would be extended.
For an LBF template, most likely the current engine could handle persisting data and an HTML template could have data handled as part of the template form similar to how the majority of our current forms are handled. Still, more thought is required perhaps concerning a generic MVC for such templates. For now Iâd keep it simple while getting the entire new pattern in place.
For the purpose of additional address etc. I would not follow my previous name input using select2 which if I had more time when I developed, Iâd gone in the direction Iâm talking about here.
Now all of this requires more fine tuning of course but, I hope the concept is somewhat clear however if not, please post a question or thoughts. Iâm going back to jamming to Alice Cooper.
