I am creating an web application that has a case screen to show the fields that belong to a case. I have made all the fields editable by setting a click action on each field that transitions to a an overlaid screen where user can edit the content of that particular field, save and go back to the case screen. Result, selected field is now updated.
Downside: X fields currently require X screens to edit the content - a hassle to update and I suspect it can probably be done more elegantly.
So my question: How should I approach creating one generic screen instead for editing the fields?
I am hoping there is a way to work with only one case screen where I show the content of the case and one editing screen that only shows the information of the field the user has clicked. There is a short explanation in the editing overlay that tells users what information they should provide. So depending on the field they have selected for editing that information should also be visible in the editing screen. Ideally also the name of the field they have selected for editing.
Restrictions:
I have chosen on purpose not to use the standard form because it has to many limitations, mainly in appearance to serve our needs.
Thanks for these suggestions! I will run some experiments with both. On the first one: will that allow me to open the editing screen with the text that is currently there? I haven’t had much experience yet with the change input value route.
I have applied the conditional visibility a lot already so that I think I should be able to make that work. It feels like it isn’t a lot less work than the multiple screens route in terms of maintenance.
I managed to create the screen and get the input field to show the value of the original field I created. A back button to cancel works fine obviously but now the next challenge is to create a save button that saves the input to the appropriate field and returns to the case screen. Do I do that with multiple buttons and conditional visibility?
I’ve tried that route but find it hard to figure out what condition I can use to make sure the button appears - and stays visible while I am editing the input
Is there a route via custom states? Although I understand that is better suited to mobile apps because refreshing in web apps also clears the custom state? That should not be a huge issue as long as it at least doesn’t cause the original field value to get lost or am I missing other unintended consequences here?
I suspect when I figure out how to save the input I might also have figured out how to show a field that shows the field name and a field description.
In Adalo, we can use text input and put it on the screen that you use for data entry, this text input later can be hidden by sizing into 1 x 1 and changed the color to transparent, which is called invisible input, which serve as variable for us.
So, at the button to edit the data, this invisible input will be assigned a number and will be different from those other datas, so if you have 10 datas that needs to be assigned to the next screen, the edit button of the first data will have action of change input value of this invisible input as 1, and other edit buttons will put different number.
Then in the edit screen, save button will have multiple update actions, differentiated by conditional, this conditional will use invisible input described above, if it is 1, then update certain field in collection, if it is 2, then update other fields.
In the meantime I have also gotten the following solution to work - at least to have the save button do what I want it to do.
Three screens:
Case screen with all the fields and current values
Clicking on a field will do the following:
change input on custom state screen text input to existing value
change input on edit screen text input to existing value
link to edit screen
Custom State screen with text input. Effectively invisible
no further actions here
Edit screen with text input, cancel and edit button
cancel will simply link back
save button updates case field to the input (title button saves input to title field etc.) This button is visible when original field value is equal to value in input field on custom state screen.
This seems to work as well.
I will try your solution tomorrow as this will also give me an index number to link to a table with field names and field descriptions!
No need to use the custom state screen anymore, created a collection that contains field descriptions etc that is referenced based on the field number that controls which save button is shown.
Only thing I am wondering: I could even size it to 0x0 so it should be completely invisible? I wonder if using f12 for example it is still possible to see hidden fields? Storing those fields on a different custom state screen would prevent that and that approach also works.
I tried hiding the field number based on a user attribute, that wasn’t a good idea. It fails when the users logs in again. Apparently Adalo stores the original attribute values for the logged in user and doesn’t change those when the user table attributes are updated.
I have implemented this successfully now, one minor glitch.
I see some inconsistent behaviour when I open an edit screen from one field, cancel and then open it from the next. The field number that is still in the hidden field sometimes - not always - hasn’t updated.
It seems when I click too fast after cancelling it always defaults to show me the edit screen with the fieldnumber set to 1 but without loading the content of field 1. Any ideas how that might be caused / and prevented?
