Right now when I add a "column" I need to add two new fields in my Courses database (AssignmentTitle6 and AssignmentDate6) and then create a new relationship which joins the credits to the class using those new fields, and then lay them out and tweak some minor layout items (hide if the assignment doesn't have a title, etc.)
Is there some cleaner (faster-loading and less fields and joins) I could make this more dynamic?
I did consider of making a separate ASSIGNMENTS table, but I think that means I'd have to add a bunch of portals and filters and I think it would actually slow things down and add a lot of complexity with very little gain.
It's not that much work, but it feels clunky and I just wanted to make sure I'm not missing some "magic" way to speed up or simplify this.
I’ve only had a quick look at your issue, but from what I can see, you have the normal problem we come across using ‘spreadsheet’ think and trying to work dynamically horizontally.
Adding columns tends to always end up with manual work and, eventually we run out of room if these ever need to be printed due to the paper width.
My initial reaction is whether you could utilise sub summary parts, so each name would be placed in the sub summary and then have a record for each subject, something like:
Name1 % Date Notes
ENG [Def Credit] [Credit Given]
WRK [Def Credit] [Credit Given]
MAS [Def Credit] [Credit Given]
Name2 % Date Notes
ENG [Def Credit] [Credit Given]
WRK [Def Credit] [Credit Given]
MAS [Def Credit] [Credit Given]
(Formatting above not displayed well I’m afraid)
I appreciate this is not as familiar as using a grid, but it allows expansion using data only without touching the structure.
An alternative would be to use something like the new JavaScript features and build a web interface in a layout that updates the data using JSON. It depends on how far you wish to move away from FileMaker’s traditional tools.
Ahhh… grading solutions… I have not touched these in years.
The principal problem is the difficulty in displaying and manipulating a multi-level data structure with FileMaker's built-in UI elements… which suck for matrices. This is a use case where repeating fields can add value to solutions.
Use a repeating field in a list view to create a matrix. Use scripts to copy the class data and populate the repeating field. The user does whatever edits he/she wants. A save button invokes a script that commits any change to tables.
Adding a new column is now simply a matter of increasing the number of repetitions and changing the layout. Nothing else needs changing if done well. One could even go a step further and plan for an excess of columns, using masking calculations and/or multiple layouts as a means of displaying only desired columns.
As far as speed is concerned, the largest speed hit will be when the solution draws the class data and when it saves the class data. UI edits should be quite fast.
This is awesome. Thanks for replying. I'm not a JS programming and not going to "learn" in a week or two, so that's out. RE the summary, let me kick it around. That could work, I just need to understand it enough to know if it's more work or less... and if I have to refresh/commit every time we add or remove credit from a record.
I do need a separate record for each credit because assignments can be done different days so we need to keep track of attendance, so I think that would stop the repeating field. I tried making the "assignment list repeating and then joining it to the credits, but it seems like it only joins on the first entry in the repeating field, unless I'm missing something. if I could make the credits (the end target) repeating I could see this working, but because this is just one of many ways that credits are recorded it wouldn't be feasible to allow one credit record to have multiple repetitions.
It's likely more that I missed something in my explanation.
The table that contains the repeating field is one used for UI purposes only. It can contain one or many repeating fields to contain all data necessary for display and manipulation, however the repeating fields do not relate to the data. Scripts are the means to translate table data to the matrix and vice-versa. Credit is just another table that the scripts would need to take into account when translating.
This approach transfers the display logic from the data structure to scripts.
oh... got it. OK let me noodle it around. My gut says that unless I'm pretty sure there's a huge speed increase it probably won't be worth it for the prototype I'm building, but maybe later...
