I want to design an object for loading and showing customized data, for example, the object firstly loads all employees in database, then look up whether login user in the list, if so then show the login user, otherwise show dummy data "all employees"(means null). But another scenario is the component should "remember" last time user selected data and show in another page, any good design suggestion?
You describe four major pieces of function:
checking the user against a list
identifying one of two scenarios
remembering selected data
using the remembered selected data
Overall I don't think you've decomposed the problem enough yet to start thinking about design patterns - patterns become important once you've identified some candidate classes and start to look at how to decouple them. So my next step would be to design some classes to do these 4 tasks and then critically example the resulting Object model, see whether refinement is needed. THe first step: identify classes with clear interfaces and responsibilities.
Related
Is it possible to materialize the edits made as part of a scenario into a dataset in foundry?
I want for each scenario to write out the primary keys of the objects edited as part of the scenario.
The motivation is that I need to run multiple processes to compute metrics as part of the changed values for each scenario, at a scale and runtime that is not possible to do with Functions.
Edit with details:
The thing is that I am not doing actual edits to the objects for the object type, I don't want to apply it.
I tested out the "Action Log" and it does not seem like this picks up "uncommitted" actions, meaning actions that is just run as part of a scenario. Also, it does not seem to be a link to the scenario it was a part of, even if the changes were committed.
The workflow is that I have Object Type A, and I define multiple scenarios S on a subset of the objects in A.
Each scenario might make something like 50k edits to a subset of A, through multiple Actions backed by a Function.
I save some of the scenarios. Now I am able to load these scenarios and "apply" them on A again in Workshop.
However I need to be able to get all the primary keys, and the edited values of A materialized into a dataset (for each scenario), as I need to run some transformation logic to compute a metric for the change as part of each scenario (at a scale and execution time not possible in Functions).
The Action Log did not seem to help a lot for this. How do I get the "edits" as part of a saved scenario into a dataset?
The only logic you can run BEFORE applying will be functions.
Not sure about your exact logic but Function's Custom Aggregations can be very powerful: Docs here
this might not directly let you calculate the Diff but you could use the scenario compare widgets in workshop to compare your aggregation between multiple Scenarios
e.g. you have a function that sums(total profit)
Your Workshop could show:
Current Data:
$10k
Scenario A:
$5k
Scneario B:
$13k
instead of like:
Scenario A:
-$5k
Scenario B:
+$3k
Afaik there's no first class way of doing this (yet).
"Applying" a scenario basically means you're submitting the actions queued on the scenario to the ontology. So neither the actions nor the ontology are aware that they came from a scenario.
What I've been doing to achieve what you're working on is using the "Action Log". It's still in Beta so you might need to ask for it to be enabled. It will allow you on each action to define a "log" object to be created that can track the pks of your edited objects per Action.
How I do the action log is:
My Action log has the "timestamp" of the action when they were run.
My Scenarios have the "timestamp" of when it was applied.
Since "Applying a Scenario" means -> actually running all actions on Ontology (underlying data) this gets me this structure if I sort everything by timestamp:
Action 1
Action 2
Scenario A applied
Action 3
Action 4
Scenario B applied
this allows you to do a mapping later on of Action 1/2 must come from Scenario A and Action 3+4 come from Scenario B.
EDIT: Apparently you might be able to use the Scenario RID directly in the Action Logs too (which is a recent addition I haven't adopted yet)
This won't allow you tho to compute (in transforms...) anything BEFORE applying a scenario tho
I'm using MS-Access (365) as a frontend to a Postgres table backend. Communications mech between them is ODBC. That seems to work fine.
Before I migrated away from the MA-Access backend, a list of check-able options would appear in a column's filter options when filtering column data. For example, when you clicked on the little carat next to the column name/header, you would see the "Sort A to Z" and "Sort Z to A" (as before) then for the filtering, you would see "Text Filters" as before (with options for specifying the filtering), but then you would also see the options, including "Select All" (a toggle) and then each value with a checkable box next to it. The user could select/deselect to filter based on the values. But I no longer see that list of checkable values in the filtering.
The column values are constrained to values in a different table which contains the valid values for that column (a traditional primary/foreign key relationship) and that works fine in the pulldown as a means for a user to pick one of the valid values when editing a record/column.
Since the values of the column are constrained in a predictable, or at least queryable way, I would think that there might be a way to use that to restore those checkable boxes in the filtering. I looked at the "Design View" of the table and tried a few things to see if I could get this to work. No luck.
Any ideas ?
You can try this setting:
File->options->Current Database-> Filter lookup options.
the real problem here is that you really should not be loading up forms with SO MANY records in the first place. But you can try the above settings - and of course increase the 1000 rows. But this is going to cause a performance issues, since this suggests that forms and view are loading large recordsets and THEN you are applying filters to that data. So keep this pulling of data in mind. It is preferable to provide some kind of search form, and let the user search BEFORE you pulled large amounts of data.
So all in all this is a less then ideal option from a performance point of view. But if data pulls are not too large, then this certainly is a "nice" feature - just not a great from a performance point of view.
I am building a database for maintenance performed on lighting fixtures, each with their own unique serial number. I already have an excel document with all this data, but want to create a better system for managing the data.
The idea is that every time I service a unit, I have a new job #, and fill out a checklist and enter notes for that job. I have created a Job # table, with columns for serial #, date received, date completed, notes etc. I have also created a job form, which includes all the relevant info for that job#. The question I have now is how to create relatively efficient checklists that modify the background color of a text field.
For the first part of this, I need to have a drop down list with different model lights to choose from(each light has different feature sets to test), which, depending on which model I select, will display/generate a checklist, with about 25 items, that is unique to that model.
Then, when all the check boxes are checked for that specific checklist, I need the background color of a text field("Unit Good?") to change from red to green. These check lists need to be specific to the job #/record #, and I'm curious if there's a relatively easy/efficient way to do this.
At present I have about 150 jobs, and it will only increase over time.
My preference is to avoid VBA if possible, but if necessary, some pointers, or recommended tutorials would be highly useful.
I've built the underlying table and form, but haven't yet been able to figure out how to do the checklists.
Any help here would be extremely appreciated. I am happy to provide any additional information/documents if necessary.
Yes, this is possible and it can be done without VBA (although macros are required).
First, you need to create a couple more tables. I'm making the assumption that you only work on one light model per job (multiple models is possible but more complex). You will need to create three tables (two if you already have a table for your light models).
Light_Models will contain information about the light models you service, including their unique serial number.
Model_Checklist_Defaults will contain default checklist values for each light model
Job_Checklist will contain checklist values for a specific job based on the light model you serviced (this is where multiple light models in a job would add complexity). When you create a job for a specific light model, you need to copy the appropriate values from Model_Checklist_Defaults into Job_Checklist (this can be done by creating a query and calling it from a macro, I won't cover this here).
These tables need to be related in the following way Relationships image. I only included the bare minimum columns, you could add more as you need.
You need to create a form to present your checklist, and optionally, other job details. This form assumes that you have already created a job and selected a light model, but you could modify the form to create the job and checklist in one step.
The example form (Form image) has a jobNumber textbox that identifies the current job, a coloredField whose background color changes based on the checklist, and a subform that presents data in the Job_Checklist table filtered by the jobNumber textbox (this filtering is with linked fields in the subform Property image).
The final piece is configuring the coloredField background color and setting a macro on the form, jobNumber and subform to update the coloredField when checkboxes are clicked/unclicked.
This macro need to be set in several places (Macro image):
Form OnLoad event: this ensures that the coloredField updates based on the checklist when the form opens (in case you close and reopen, for example)
jobNumber AfterUpdate event: this field updates the checklist subform when its value changes, so you have to recheck the checklist values each time
subform OnExit event: this event is called after you have clicked into the subform (checking a box, for example) and then clicked on another field in the main form. This event catches the actual checkbox changes.
I've been trying to whip up a simple MS-Access task-tracking application for personal use. My basic data model is a task-definition table (in which I can define daily tasks) and a task-result table (in which I can track which tasks I've performed on a given day).
I'm trying to build a form which
1) lists all daily tasks (sorted by time-of-day, an attribute of each task), and
2) next to each task, displays a widget that lets me mark the task as complete.
Here's the rub, though. I have three (and may add more) different types of tasks:
simple yes/no tasks (for which a single checkbox widget would work)
score-able tasks that allow me to track how well the task was done (for which a radio-button group would fit), and
"complex" tasks comprised of several yes/no sub-tasks (for which a multi-selection list-box would fit).
I've gotten as far as building the form so it lists all tasks in desired order, but I am 100% stuck on how to code the (conditional) data-entry widget. Though I've had no difficulty in implementing each widget individually, my best effort is a task list with just check-boxes, just radio group, or just list boxes. I have no idea how to tell the form to "look at" the type of each task and present the appropriate widget beside it.
I'm almost ready to throw in the towel and just hard-code all the tasks into the form, in a fixed order, along with their appropriate widget. Is there a way to implement this in a more elegant manner?
[an aside] I chose MS-Access somewhat arbitrarily, and am learning MS-Access forms as I go. If anyone feels I'm stuck by virtue of choosing the wrong tool for the job, feel free to let me know
As resolved in the comments to original question, it seems the main obstacle is the limitations of continuous forms. Because Access treats each column of continuous forms as an atomic element, there are very few options available to differentiate their presentation. The only tool that comes close is Conditional Formatting, and the closest approach to selectively hiding/showing fields is to hide text-box fields using text colors that "camouflage" them into the background color.
This limitation leads to my potential work-around.
To recap the objective: Within a given day, I want to list a [table-driven] set of tasks. Each task has options of "Yes/No", "Choose one of N choices", or "Choose 0 to N of N choices". Depending on the type of task, it should be rendered (respectively) as a single checkbox (yes/no), a radio button group (choose one), or an checkbox group (choose many).
(An aside: I realize, as I type this, that the first type is really a subclass of the third type, but that doesn't really make the core issue go away)
The proposed idea:
At the time the form is launched, a query can be run which will tell exactly which task will fall into exactly which position. In other words, before "drawing" today's tasks, the database can answer which task will be in position 1, which will be in position 2, and so on. Additionally, I can safely say that there will never be more than, say, 20 tasks (though the actual number of task on any given day can vary).
Which leads me to wonder: what if I designed the form with 20 "slots", and in each slot, had 3 overlaying presentations: one for Yes/No tasks, one for a "Choose one" tasks, and one for "Choose many" tasks. (60 total - sounds horrific, but I'd hope copy/paste would come to the rescue).
When Access renders the form, each slot would query for the "nth" task of the day (so the 1st slot would query for the first task, the 2nd slot for the second task, and so on). The "visible" option would then be set to "Yes" for only the presentation that matched the type of task returned by the query. So if the 3rd slot, querying for the 3rd task, received a task of the "yes/no" variety, only the "yes/no" prompt would be displayed.
For what it's worth, I do have a working version of my application already (though checking & unchecking check-boxes according to whether a task is labeled as "pick one" or "pick many" definitely grates on me). So if there's a reason to think this new approach won't work, I'd be happy to hear it before I throw any real development time at it.
I am working on Audit Trail for my project and I have been asked to think of how can we display the fields which have changed between two versions. I have the list of changed fields I am looking for suggestions on how to display the fields so that user can easily find out:
which fields have changed
what was the old and new value
A simple approach will be to display the old and new values in grid with the top row showing new values and the bottom row showing the old value.
But this one is very basic approach
another one i thought of was to display the changed fields in color so that the user understands that these fields have changed but in this case he will not be able to get the old value of the fields.
If any one has some innovative ideas kindly let me know.
Thanks
Your idea of showing colours would be a good visual aid, but perhaps a list of changed values below the main record would also be beneficial, so you could have an "at a glance" view.
Something akin to:
Firstname: Phil -> Philip
Email: phil#example.com -> phil#someotheremailprovider.com
A bit more innovative, but non standard so potentially open to usability/training issues, would be the coloured input field that when you mouseover/focus launches a bubble to the side with the old value.
Several possibilities come to mind whose suitability depends on the user’s task (doesn’t it always?):
Task: Get a general quick overview of how things have changed in a window. Here the user needs to compare the old values along with the new, but doesn’t necessarily need to check every single field.
Design: Provide a toolbar button and/or accelerator key that swaps the new values with the old. If this can be done instantly (<500ms), the apparent animation will naturally draw the user’s eye towards places where the greatest changes were made. This is especially effective if the content is graphical (e.g., slider values, graphs, or editing an image)
Task: Crosscheck every change of every field to make sure new values are correct. In this case knowing the old values is at most a secondary task (i.e., only occasionally will a user care what the field used to be).
Design: Prominently mark the fields that have changed (see last paragraph) and show the old value as a tooltip with mouseover.
The above designs have the advantage that you can use the “normal” window intended for non-auditing purposes, cutting down on the number of windows users need to learn.
Task: Detail evaluation of how each field has changed, including perhaps a long history of multiple changes for each field, followed by occasionally correcting a value based on the history.
Design: On selection of a menu item, the window expands vertically to show old values in a read-only list below each new value. For long histories, such a list may need a scrollbar. For most alphanumeric values, it’s easier to scan vertically to see how things changed character by character than to scan horizontally. You should allow the user to edit values when in this mode and also select a value on the history list to revert the field. Saving pushes the now old values of edited fields onto the list. Tooltips may be used to provide secondary information (e.g., when each value in the history was entered and by whom).
Design: For “heavy” fields, like a large rich-text box, consider a display mode that uses strikethroughs and highlighting to show changes within the field, such as done by MS Word in Track Changes.
The above two designs still use the “normal” window, which minimizes learning, but modifies the window’s size and layout, requiring somewhat more learning and re-orientation than the first two designs.
Task: Find when and who changed specific fields. Here, the user already knows or suspects which fields have been changed and what the new values are, but now wants to know how they got that way.
Design: If the users generally needs to check only one field, then a menu item opens for the field that currently has focus a small window with a grid listing the history of values, who changed them, when they changed them, and any other auditing information (e.g., who approved it and when). If histories tend to be long, provide sorting and/or filtering. You can provide a command button that sets the current field value to one selected from the history grid. Note that this is different from the list using tooltips in that the user is primarily interested in figuring out who and when the field changed, not in what the field should be –it’s easier to scan through the timestamps, but harder to revert a value.
Design: If the user is likely to need to check and compare multiple fields in a window, provide a closeable history pane rather than a window. As the user tabs through the fields in the window, the pane updates instantly with each field’s history, complete with timestamps and usernames. A menu item can revert the field to a value selected in the pane. This is suitable for a user group for whom auditing is a fairly regular task, not an exception rare done.
The above two designs minimally disrupt the “normal” window, but require the user to learn an entirely new window or pane.
Task: Reconstruct the evolution of data objects through multiple updates of multiple fields. In this case, correcting values is not part of the task.
Design: Provide a general audit window for any arbitrary list of fields or objects, allowing the user to query/filter by fields, field values (e.g., to answer, “when was this ever X?”), windows, database tables, and, of course, timestamp range. In addition to supporting ad hoc query, you can allow the user to open the auditing window for all the fields shown in their current window. You can also provide an easy way to populate this table with fields the user regularly needs to audit or with fields that automation determines should be audited. The audit window shows a sortable grid listing the timestamp, data object (or table), field, old value and new value, and username. When sorted by timestamp (perhaps should be the default), the user can infer how changes influenced each other across fields (e.g., User A change X to 2, which probably led User B to change Y to 4). You may want to provide graphing options to help the user see correlations in changes. This is the most powerful auditing tool of the designs I’ve given, but it also requires the most training and skill to use.
For all the designs, it’s indeed a good idea to color-code recently changed fields to help the users spot what they are likely looking for (i.e., something different than the last time they looked). You may even want to have three or four gradations of recentness. I’d choose a bright color to suggest “newness,” but I’d avoid red which implies something wrong (not necessarily the case) or a required field. How about a sunny yellow “halo” around the field? Something like border will avoid issues with readability of the field. For accessibility reasons and better self-documentation, I would also include a redundant cue such as an alt-tagged icon (maybe a “sparkle”?) or simply the word “new” beside the field.
If each field contains fairly simple data then I might just have back and forward buttons so that you can toggle between previous and current view. In the current view (or perhaps both views) highlight the fields that have changed. The previous view should provide some visual cue that the fields are disabled (like greying them out). This gives you locality with respect to the change set (i.e. the user can quickly see what values changed) without too much visual clutter.
I'm lazy, so:
Turn the old data into text
Turn the new data into text
Use diff to show the differences
Educate users about how to interpret diff output