Well @ihsanzainal84, I think this question is more about passing a list of items to a subsequent page. You can do this with browser storage (using Floppy for example) and you can also do it with a URL parameter. I think the concept that @dalatcafebestilling is missing here is that in a “shopping cart” type scenario (which this clearly is), the Bubble way of doing this is to create a new object (Thing) that is an Order, which is composed of Line Items, which is a list of the Dish/Product in question.
I know that a lot of times people are like, well, I want to do that without immediate interaction with the database (and while of course this can be done, Bubbble doesn’t make that particularly easy). But I don’t think that’s so much the question here.
@dalatcafebestilling, if what I’m saying above doesn’t immediately make sense, you might find the video in this post helpful (there is also a lot of interesting discussion in the full thread itself that you might find inspirational/helpful):
EDIT: I previously posted the wrong link. Here’s the post/thread/video that I meant to link:
(1) the only support for createable/updateable/modifyable objects we have in Bubble are Things (caveat - API response objects are Thing-like but suffer from the same sort of issues as Things)
(2) Things only exist in the context of the database (creating a new Thing requires interaction with the database, a Thing cannot be created purely server-side, and there is no way for us to create an object that is like a Thing in a plugin and bring it back into Bubble as something that the Bubble programmer can easily deal with.
(3) Somewhat related is the fact that there is no client-side action for creating multiple Things at once (there’s no “Create a List of Things”)…
So, in the case of a shopping cart where a user is selecting some items and their quantities, if I don’t want to organize them into Things yet, I wind up with parallel lists: a list of items (which are probably already Things of course) and a list of numbers with represents the quantities (I might additionally have other lists such as a list of discounts or tax rates or whatnot).
If I want to pass those values now to some other page, we could do it with URL parameters, but vanilla Bubble doesn’t expect array values here so we would have to parse them ourselves (this was the point of Floppy Rehydrator, you might recall). Also, those URLs are gonna be pretty ugly, so browser storage using Floppy/Floppy Reader is a more elegant solution.
Regardless of whether I pass/store/retrieve those values somewhere else than the original shopping cart page, what we then have to do is turn them into objects we can work with (Things) and so typically we would then pass those “parallel lists” of values to a recursive backend workflow that converts them into things (e.g., make an order, take the first set of values and make a line item, attach the new line item to the order, recurse to make the rest of the line items, then process the resulting order (whatever business logic your app requires).
That recursion is made much easier using my List Popper plugin and this is demonstrated in the video I linked to before. (Also, most of the preceding issues are discussed – except for browser storage – in the video I linked, which I’m gonna paste again below.)
Instead of a recursive backend workflow, we might instead use the bulk create API endpoint to create our desired Things, but this is a bit of a pain to set up (I had been thinking of making a little plugin that makes that a bit simpler for folks, but whenever I start on that I get grumpy about the interface – we can make it a bit simpler, but can’t entirely make it hassle-free to the Bubble programmer).
Anyway, here’s the video about shopping carts that I’m referring to (I posted the wrong link before):
@keith I think that another big plus to doing it your awesome way (list popper) vs the traditional bubble way that you don’t mention in the video is that in the latter, you can potentially end up with tons of orphans from abandoned flows; something that isn’t so with your “proxy” datatype since you can clean that up at the end of the recursion. I’m on a messy app that I inherited that has lots of these “cart” type lists attached to a main datatype – pricing tiers, discount tiers, category tiers, etc. and currently they’re populated in the DB every time you create them on the main DT creation page, but before the main DT is saved.
Not sure if there’s a “best practice” for how to handle this. Perhaps it’s better to create all of these sub lists into their respective temporary (or “proxy”) DTs and then merge them into the actual DT for those lists.
What you’re proposing probably makes sense. And yes, if doing things “the Bubble way” one does have to periodically clean the database of orphaned/abandoned objects.
I am messing about with a plugin designed to make working with one’s app’s bulk create API easier (I haven’t messed about with bulk create much though I know others here make use of it regularly), but that also (as Bubble warns) may cause capacity issues as well. I just don’t have a lot of first-hand knowledge of how hard you can use/abuse that for these sorts of use cases at the moment.