Hi all,
I use the anvil-extra “custom signup flow” app as a dependency in my app. However I have added an extra field in the dependency that is a drop-down asking the user what property he lives at, and a textbox asking the apartment number.
Then I’d like to check whether that apartment number exists at that property, and if so, allow the registration. If not, disallow the registration.
What is the best way to implement it? Currently I call the “signup_with_form” method on the dependency, from my app, and pass in a list of all possible apartment numbers. Then in the dependency, my modified “signup_with_form” method accepts the list of apartment numbers as a parameter, and when the user hits Submit, I check the input box of apartment number against the list of passed-in possible apartment numbers.
This worked okay as long as there was only a single property, but now that I have more than one, I don’t know which list of apartment numbers to pass into the signup_with_form method of the dependency, because I don’t know which property the user has chosen yet.
I’m sure I haven’t done this in a very logical way, but I’m not sure what the best way to implement it is. Should I modify the dependency to include all of my data like properties and apartment numbers rather than trying to pass data to the dependency from my main app as parameters?
Thanks.
Personally, I use dependencies for generic features that can be used from many apps. So I wouldn’t push more app specific detail into the dependency. Instead I’d pass arguments to the dependency giving it all the extra detail it needed, probably with a callback function to use to verify the input.
But in your case you’re already putting app specific detail into your dependency, which means you can’t use that dependency in other apps anyway. The simplest approach would be to embed the extra detail you need in to the dependency.
At that point you have a dependency that can only be used with the one app, so you might as well just integrate its forms with the main app.
2 Likes
Thanks Jay. That’s what I was thinking as well. The dependency is only being used in this single project, and it’s already been customized for that, so I may as well continue making changes in the dependency.
Functionally, if those values are required for successful sign-up, then I would probably arrange a custom sign-up form to enforce that.
That is, fields would be enabled one at a time: first location, then apt #, then username, then password, then sign-up button. This forces the information to be provided in an effective order.
2 Likes
Functionally, if those values are required for successful sign-up, then I would probably arrange a custom sign-up form to enforce that.
That is, fields would be enabled one at a time: first location, then apt #, then username, then password, then sign-up button. This forces the information to be provided in an effective order.
You mean create another form to gather the required data before calling the custom-signup-flow dependency and piping the captured parameters to it?
No, I mean putting them all on the same form, in the order needed, and enabled only in the order needed.
Edit: For example, until they’ve chosen a location, they don’t get to enter the Apt# or anything else. Choosing the location also chooses the list of valid apartment numbers, so then it’s okay to enable the Apt# choice.
But the dependency doesn’t have that data currently - it doesn’t know which apartment numbers are in which properties. So I guess your approach aligns with adding that to the dependency itself, and then exposing it based on the previous responses, rather than piping that data in via the main app, right?
The layout solves this part of the problem:
by making the signup_with_form method ask for the location.
In the location DropDown’s change()-event handler, the location becomes known, so it can then populate the Apt# DropDown with the corresponding list of valid apartment numbers, and enable the Apt# DropDown.
Whether the set of locations (and corresponding Apt# lists) is embedded in the Dependency, or is passed to the Dependency from the calling App, is an entirely separate matter, and could be solved either way.
However, to reduce maintenance of the Dependency, I’d be inclined to pass that data, rather than embed it. Depending on how stable the data is, it might even go into a database Table, for the Dependency to look up. This would avoid having to change either set of code; just update the Table.
If you wanted to make the dependency more generally useful, while also maintaining the app specific data, you could look at creating the extra form fields needed via code according to data passed in via the main app. Then you’d also pass in rules for what numbers are in what locations, to use the flow Paul suggests.
That’s a more major effort than just making the dependency app-specific, though.
Thanks guys. I will take the simpler approach for now, but if more flexibility is required in the future, I will pass the data from the main app.