2024 R3.1 Container Desctruction

Hello all,

I have several instances where a container, has several other containers with it. These are all created using EmbeddWithin.

What is the best way to handle container destruction?

When the mother container is no longer used, do I first need to destroy any instances of sub containers? Or, will they automatically be destroyed once the Mother Container or web page is closed?

What are best practices?

Thanks,
Tim

Unless you’re holding references to them elsewhere, or the embedded containers hold a reference to the parent, simply destroying the parent should take the children with it.

2 Likes

In line with this question Greg, where is the memory held for Containers, and the objects/data within them? Is this done on the server or the client browser?

I ask because I am curious which would be better. To destroy them as the user is finished (or so we think) with each, or leave them open and close when the page closes?

In my case, I have a menu that creates a new set of Containers, each having a different function. The user will view or enter/edit info, then save it, or just view it. Then go onto another menu that will do the same thing, only for different data. This can continue on so there potentially could be 20+ containers open. Since this is a web app that will be on a cloud server, keeping costs down will count.

What do you all think?
Thanks
Tim

It’s a little bit of both. The web framework is made up of both a Xojo framework and one written in JavaScript. The part that you create in Xojo code lives on the server and is responsible for sending property updates to the JavaScript version that lives in the users browser.

Honestly I don’t think there’s going to be much of a difference unless you’re talking about hundreds per user at a time.

It really depends on which memory you want to optimize - the server or the client’s browser.

Hi Tim,

I want to use the least amount of resources on the Server as is practical.
Tim

Then delete them as soon as you create the next one. And that could be as simple as reusing the property that holds the container reference.