Need Help Tallying up the number of boxes a user checks

Need help
1

Hello,

I would like to have users check boxes, labeled from 1 - 100 (100 check boxes). I would like the database to produce the sum of only checked boxes. I am stuck at the moment trying to get the add button to tally up all of the checked boxes. FYI: I set the boxes to be dynamic. Maybe there is a more simple way to go about this?

Ultimately, it is a daily tracker (100 days) where users will mark (check) when they have completed the specified tasks. Eventually they will click the add button to tally up their points (checked boxes).

2

If you have that many checkboxes you’re going to tear your hair out at some point.

You’ll want to think about this differently. You might find this helpful:

3

Thank you sir! Question, how can we have the db add up all the checked boxes so that we can create a workflow to generate the total number of checked boxes?

4

So, I’m not sure if you’re asking: “If I use your technique to build up a list of things representing checkboxes that have been selected, how do I know how many are in that list?” … Or if you’re simply re-asking your original question.

In the case of, “How do I know how many things are in that list of selected items?”, the answer is, it’s just the :count of that list. (So, in my “amenities” example, if we are pushing selected amenities on to a list on an object called “Property” as “Amenity List”, the number of amenities associated with a given property is justProperty's Amenity List:count .)

If you are just re-asking your original question: The answer is there is no easy way. Consider the following:

Let’s say we have a data type called HundredDayTracker. On HundredDayTracker, we have 100 boolean (“yes/no”) fields (which we could of course represent in a UI as checkboxes). These might be like “Day 1 Completed” (yes/no), “Day 2 Completed” (yes/no), … “Day 100 Completed” (yes/no). Again, let me just say this is the wrong way to do this… But to continue…

There is no built-in Bubble function that can tell us how many fields of a given type are present on HundredDayTracker. We can’t query anything to tell us how many fields are called “Day X” on that object. We can only know that in vanilla Bubble by examining the data type on the Data tab.

Further, because of that, there is no way for us to know how many of those boolean fields are “yes” and how many are “no”. (You’d have to make a 100 step workflow that goes and checks the values of these discrete yes/no fields and does something in response. That would be kind of silly and not performant, but you could do that.)

This is just the nature of fields on a data type in Bubble.

So don’t do this.

Instead, you need to design a data model that can tell you what you need to know programatically. That the user has completed a set of tasks on “Day X” is a dynamic state that’s perfect for tracking with a list of things.

One way to do this might be as follows:

You have a User who is doing something in your system for 100 days. We want to track for what days within that 100 day period the user completed a set of tasks.

So, when the User begins a 100 day tracking program, we might create a new thing like Hundred Day Tracker. This version of Hundred Day Tracker might have fields as follows (it could have many more, but at a minimum it would be):

  • Start date (type date)
  • Tasks Completed (a list of type “Task” or “Task Complete” or “Goal” or whatever, it’s a custom data type. I’m going to call it “Task”.)

We don’t necessarily need to have a “User” field on the Hundred Day Tracker data type as the User is implicitly associated with this Tracker. (The User will be this Hundred Day Tracker’s Creator.)

Now a Task data type would have at a minimum the following field:

  • Day (type number – when we put a value in here it should be between 1 and 100, representing the day of the hundred days of tracking we are doing)

So, what we do is, when the user completes the required tasks for day X we create a new Task, put the day value in Day and push that task on to the appropriate Hundred Day Tracker’s list of Tasks Completed.

That Hundred Day Tracker’s Tasks Competed:count will be the number of days for which the required tasks were completed. If a user completes the 100 required things, at the end of 100 days, the :count of this list will be 100.

Obviously there’s a bunch of other logic to this, but hopefully that gives you the basic idea.

You might also want to ALWAYS end up with a Tasks Completed list that has 100 items. That is, for each Day in the Hundred Day Tracker, there should be a Task object and the state of that Task object should track if the required things were done.

In that case, a Task might have fields like:

  • Day (type number – when we put a value in here it should be between 1 and 100, representing the day of the hundred days of tracking we are doing)
  • Completed? (type yes/no – if the user completed the required tasks on Day, we set this to yes. If the user did not complete the required tasks we set this to no.)

We could then do things like: The number of days for which tasks were completed is Hundred Day Tracker’s Tasks Completed:filtered [where Completed? = yes]:count. The number of days for which tasks were not completed in Hundred Day Tracker’s Tasks Completed:filtered [where Completed? = no]:count.

(But as you can see, we could always algorithmically get the number of “no” days as that’s 100 minus the :count of the list of Tasks if Tasks ONLY represent completed task days.)

Again, this sort of thing is easier shown than described and my video on amenities should get you going.

Basically you need to track this “state of having completed some goals” not as a simple set of discrete fields on some object but as a list that gets dynamically constructed by your app.

5

This topic was automatically closed after 70 days. New replies are no longer allowed.