I am trying to use Fibery as a basic CMS. I am planning some courses, that each have lessons. The lessons need an order.
I can put a # field called Order. Is there a way to enforce uniqueness, so I don’t accidentally put the same number twice? Or is there a simple way to define the order of the relation, so I don’t need to type each number? Imagine I decide to add another exercise to the beginning of a 100 lesson course, then I have to basically change every number after it manually (or I guess I could make it -1, but then I’d still have a problem if I wanted to insert something in the middle).
If lessons can belong to multiple courses, but another course has the lesson in a different order - do I just need to create a new table, that holds its own order value? Like an intermediate join table?
I guess a third question - am I abusing Fibery? Is this all a bad idea?
I think it’s a real good idea The beauty of Fibery is that is super flexible and that you can create workarounds when needed.
When you use list view (or the new experimental new grid view!) you can change the order of items when you drag & drop.
For your situation:
- Link the lessons to the applicable course(s)
- Create a list/grid view per course.
- Level 1: course / Level 2: lessons.
- Create a separate view for course A and a view for course B.
- Use filter to only show the lessons that belong to course A or B.
- Order the lessons in each view via drag & drop
Only thing to be aware of is that you can’t use any other sorting (like date or name) when you manually want to sort them
Oh man I saw that you guys responded super quickly to posts, but somehow I never thought that would happen to me. Thank you!
I think I get it. Great. I’m still a little fuzzy on exactly how I’d resolve everything via API. Perhaps a naming convention for each view, but I’ll cross that bridge when I get there. This works great for now, I wasn’t using the “view” abstraction at all.
I’ll just add that Fibery does not natively offer validation on data e.g. enforcing that a field value must be Unique (different to all existing values).
However, every entity has a public ID which is a string of numbers which will be unique (for all entities of the same type).
So if you have several Tasks, they might have public IDs 1, 2 and 3. No other Task created in the future will use any of these values. Even if the Task with public ID of 2 is deleted, no other Task will get public ID of 2.
If you need ordering of items, but based on their relation to another type, e.g. ordering of Tasks that belong to a given Project, then there are a few options, but the optimal option to choose largely depends on what your ultimate purpose is.
If you need to have an actual field that you can sort by (e.g.
Order) you could consider adding some complexity with a previous/next class relationship. If you have multiple courses, you might need to have multiple previous and next classes, which will make things a little more complex.
Then, you could have two automations:
- If my reference to the previous class changes, update my order number to
previous + 1 (and
1 in case there is nothing previous)
- If my order number has changed, update the order number of my follow-on classes to
the max of (mine + 1) and (next + 1)
Happy Jenga-tower building!