all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Blue
|
|
||||||
|
||||||
|
|
|
Notes:
|
|
-What if we used JSON objects inside of adilas to store custom settings for different pages. This could be report assignments, report settings, dynamic filters, etc. Think of the old “Mend & Repair” section but use objects to store data and criteria vs. 100’s of different form fields. Let the JSON (java script object notation) object flex up and down as needed. This could allow one single table to hold data for all possible custom settings and custom reports. That could be super powerful! -Along with custom settings, we could even scope or do some internal mapping to FORM’s, URL’s, and variables scopes. Maybe even session and application scopes if needed. -If we used internal objects, we could use a simple table that was tied to specific pages, one or more users, etc. Think user specific reports, corp specific reports, etc. -If a specific report setting was passed into a page, we could go directly to that page, its object (search and filter criteria), and display the results accordingly. That would awesome! We could use this small pass through to allow users to set up their own buttons, links, and drill-down options. Mix custom code and in-line settings to get a super user-specific interface. This could end up being the “my favorites” section of the application. -If you used objects to store settings, you could store as much or as little data as needed. The object would flex up or down as needed. This could even be which fields to show, what order to put them in, and which criteria of filters to use. -We could establish dynamics for dates as well. This would allow for hardcoded dates or mobile and flexible dates or date ranges such as: current date, current week, last week, next week, tomorrow, yesterday, this month, last month, next month, etc. If a flexible date was used or stored, the system could figure out those settings on the fly. That would allow reports to roll or move forward or backwards as needed. Basically, time keeps moving, by allowing the dates to move, the reports are able to keep up without changing the dates all of the time. Think dynamic! -If you use objects to store data… you could potentially use a general database to store the objects and yet get tons done without having a specific field for every little setting. Let the objects carry and hold their own baggage. This is very flexible for unknown or changing pieces however may not be ideal for standard one-to-many relationships. Basically, I’m trying to say, yes, this does exist and is very powerful but may not be the best option for every scenario. Mix and match as needed! That is the key! -I could see objects being used where criteria, mappings, and flexible options are needed. Where things are known or standard, I could see using traditional relationship models being used. -As a note, the application flex grid (business to business flex grid tie-ins) may need mappings and settings stored at an object level. There may be some unknowns or super complicated pieces that could be tied together with objects vs. traditional fields and columns in a database. -If all data is live and searchable, I do see a smaller problem searching objects vs. searching pre-filtered database rows and columns. To the user, they just want to search their data. To the backend developers, that means knowing where things are at and how to get to them. Things will be buried deeper in code vs. on the surface level. -There are some modern terms that we might want to check out. They deal with objects and such. They are: NoSQL, NoJS, JQuery, Ajax, etc. -While on a walk with my dad this morning, we were talking about objects and options. I had the idea and thought that objects may be a way to store in-line custom code and settings. We could provide a front-end interface with options and point and click form controls. We would then roll all of that data up together and store it in a general object. Basically, instead of having a field and table for every option, we could code the options into the object. The database would then be the storage engine and then code could be stored in a generic container. Anyway, I think it could simplify storage needs and account for future growth and options. -Another thought along those lines are dealing with elements of time and holding and storing custom JSON objects as a sub of time. This could be in the sub comments (already able to store HTML and large amounts of text) section if needed. -Another thought was to create objects and send them back and forth to represent physical one-to-many objects inside of adilas. For example: If someone passes in the invoice number of 500, we could put all of the invoice pieces into one return object and then pass that whole object back to the user. We could pass like data, relationships, subs, and even other pieces in a virtual one-to-many relationship or object. Help make the pieces be mobile and consumable. -As an option for group players and custom code options… what if we treated each section similar to elements of time and master time templates. We could figure out the options, settings, and built-on functions for each main player group. We could then save those options as an object. If someone wanted to tweak out the options, they could pull up the main group player options, change what was needed, and then reset or submit the object to be held in the database. -Using objects could even expand the flex grid and add one-to-one or in-line code options right to the main object or player groups. Say you wanted a new field to be stored per invoice. Instead of using the existing flex grid tie-ins to create the new field, what if you went to the main object itself and added a bolt-on piece right to the main object. The upper main object level could then control the sub items and the data storage level. Basically, define the additional field and store them in an object at the root level. Then store the extra data at the individual or data level. Both the group definitions and the individual object pieces would be stored as JSON objects. The system could then interpret the results. -If we got into storing pieces of code and settings as objects, one of the tricky pieces would be showing, placing (location), and formatting the output. Another tricky piece would be validation, search ability, and defaults. Anyway, it does get kind of deep fairly quickly. However, if dynamics are needed, this may be a great option and/or tool. |