I have a page where user can enter up to 5 account signers. Each account signer has primaryEmail, recoveryEmail, cel, etc. When I set each signer up as an individual qodly source object (5 objects total), I have no problem attaching the object qodly source to a text input, ie: signer1.primaryEmail can be used as qodly source for the related text input component. However, I have trouble setting up the signers as an array/collection of objects. ie When I create a qodlysource array of 5 signer objects (which seems to work fine) and then try to attach to the text input component I get error. ie: signersArr[0].primaryEmail for the text input I get a non existent qodly source err? Am I missing something? or should I just use the 5 objects instead of 1 collection of objects to hold the signer data?
Hello Robert,
Currently, collections cannot be directly accessed using an index, such as signersArr[0].primaryEmail, since referencing individual elements of a collection explicitly in bindings is not supported.
Therefore, what you did is the right approach. If you only need five signers as objects, using five separate objects is the simplest and most reliable solution.
Additionally, if you extract the object from the collection, you only need to initialize it and save it, and it will automatically be added back to the collection, but in both cases, you will need to handle the collection through code in order to save the data to your database.
Alternatively, if needed, depending on your use case, if you can use entities to directly save data to your database, it will only require you to use one qodlysource of type entity, referring to you Signer dataclass for example, initialize it, then bind your text inputs with the wanted properties, save that entity with a button click, and immediately create a new entity after each save. This approach enables a dynamic saving process, to handle an unlimited number of signers as needed.
In the case of using an entity per video above, say: qodlysource named userentity.
I bind the first text input to userentity.name and the 2nd input to userentity.age
I enter somevalues and click save.
Entiy is saved to DB
What happens when I click the “New Object” button?
Thx!
In your case, since you’re working with an entity and not an object, clicking the “New Object” button won’t have any effect because the used qodlysources are not the same.
However, in the video I shared a few months ago, I was working with objects and collections, where the “New Object” button was bound to a standard action that explicitly creates a new instance of the object, effectively resetting the form for a new entry:
That said, you can modify the standard action of the “New Object” button, or rename it to something like “New Entity”, and use it to trigger the creation standard action of your entity. This way, your form would reset and behave similarly whenever you click on the “New Entity” button, allowing you to enter new data just like with objects.
So if i create a userentity on the page. I enter some attribute values, then i “Save” it. My assumption is that the entity on the page now is == to the entity on the server including the ID field. So after saving an entity if I were to display a dialog with usernetity.ID I’d see the ID for the newly saved entity.
If i clear the attribute values and change any attribute values and save it again, my assumption is that im just updating the entity already saved to the server, not creating a new entity.
Could you clarify/confirm below:
Assumption: If i apply the standard “Create” action targeted to a standalone entity qodlysource on a page, all association of that entity to the previously saved entity is lost and all values set to null.
However, if i simply update values of a shared entity across pages and resave a few times, without applying the Create action, i am updating the same entity on the server multiple times.
Correct?
Yes, your assumption is correct. When you apply the standard Create action to a standalone entity QodlySource, it will creates a new, empty instance of that entity in memory. This action effectively resets all fields to null and removes any association with a previously saved entity, as this is a brand-new instance not yet persisted.
On the other hand, if you update a shared entity across multiple pages without invoking the Create action again, you will continue to work with the same persistent entity instance, and each save action simply updates that same record on the server.