For every foo, I have one or more bar.
Each bar has one or more blee.
Each blee has one or more quuz.
I can get the list of all foos via AJAX, in convenient JSON form. By passing up my foo, I can get a list of all bars associated with said foo. By passing up my bar, I can get a list of all blees associated with said bar. And so on with quuz. With Perl and DBI and JSON, this is relatively easy to do.
Now, I have a web interface for all this, with
select dropdowns. When you choose a foo, all the current bar, blee and quuz selects are emptied and refilled.I start out with a empty position for foos and blank bars and blees, one with no value. When I choose a foo, it gets the bar and fills that
select, with the empty position selected. Well, the boss wants it so, if you choose a foo, the top bar is brought up, the top blee of the top bar is brought up, and the top quuz of the top blee is brought up. Thing is, by the time that we're trying to load blee, quuz might've already been starting.It's the timing of the deal that I think is the problem.
I had a similar problem with ajax calls. I had jack dropdowns: building, Floor, room, jack. One would populate the next and then the next etc, just like yours, except I didn't automatically pick the top selection.
ReplyDeleteWhen making multiple calls to any API/framework/database I always ask myselfr: What do you know when calling the second call, that you didn't know with the first call. The user hasn't put in more data, so is there a valid reason for more load on the other end of the pipe? Could you have done all the work with the first call?
I would suggest re-engineering your calls just a little bit so that when foo is changed, your backend assumes that you will want the first bar/blee/quuz. (similar assumptions for bar and blee).
This way you only need one ajax call per selection onChange.
Thanks. I've spent most of the day looking through it, trying to find a better way to do it. It will require me to remember how to do joins, but that's OK.
ReplyDeleteWhile using a join might be preferable, it might not as well. Also, a single ajax call that executes 4 sql statements is much better than 4 ajax calls.
ReplyDeleteIf there is a way to do what you need in one sql that would be great, but if it makes your code really funky later, then I would say to skip the join.
I realize that it is possible that I totally misunderstood you, so that makes this entire post useless (except the bit about keeping the code simple, that always applies).