Model Life

[Shaggy Hiker]

I'm working on a design that is a bit annoying. There will be perhaps as many as two dozen simple pic lists that the user can make selections in. In reality, no user will ever make a choice in more than one or two, as these are just filters for a BIG dataset. Once the user has made their selections, they hit a button and see the results.

Building the pic lists is fairly trivial. Each one is a simple query, so I can build all the pic lists into a model that essentially wraps a dataset. Each one of those simple queries are essentially "SELECT DISTINCT", so I'm just looking for the unique options from a table.

The thing is, any choice made in any of the pic lists will GREATLY reduce the options in the other pic lists, but I'm not sure I can do that in practice, and that's what I'm asking about. For example, one of the pic lists has a series of years. Most people will choose only one, though they might choose a couple. Either way is about the same. If I were to incorporate that information into my "SELECT DISTINCT" queries for the other pic lists, by adding a "WHERE Year= X" clause, some of the other pic lists would be down to just a few options.

In a desktop application, this could be solved fairly quickly. For one thing, re-querying the DB once the new information is available would be trivial. I don't think that's the case for web pages, but I'm very new to web, so I may well be misunderstanding. My understanding is that, if the user selects something in one listbox, the other listboxes can't change without a postback. On the server side, I can't hold enough information (and certainly can't pass it to the client) to allow the filtering to happen outside of the DB.

Perhaps a postback isn't so costly? If the model has to be rebuilt on every postback, then it isn't worth it. If that's the case, then I'll just give people the pic lists and let them choose whatever they want. If the model doesn't have to be rebuilt each time (which would mean that the server would have to retain some state between calls, which might be too costly), then I can see a way to greatly improve the performance, as the first choice (ANY first choice) would allow me to get a single datatable from the DB that could be used to offer up dataviews to populate all the piclists. The user would have to make some choice, then the model would be able to get a single datatable to speed up all subsequent choices.

So, am I understanding it right? Will the model have to be rebuilt on any postback? Is the cost of retaining state too high? I don't have a good enough mental model for how web pages should work to know how to estimate this.

[jmcilhinney]

It sounds like you should probably be making AJAX calls. When a "parent" filter changes, you make an AJAX call in your JavaScript code that returns JSON and you repopulate the "child" filter(s) from that JSON.

[sapator]

I concur on Ajax calls but how will be about if you are using the standard listbox of asp.net? It will still make postbacks...Maybe? Have been years but let me tell you it will still sprout ugly unnecessarily code on the page. In general if the directive is runat="server" it is a server control so I think it will do postbacks.
IMO you might be better of with not using asp.net controls at all just div containers with html code. At client click do an Ajax call get the number of images, add <li> x times with the appropriate images.
Some lists here https://freefrontend.com/css-lists/
I admit it might be tricky to do in JS at first, heck I have forgotten how to do so, and I was good at it but there would probably be some free html frameworks for it like angular (https://codepen.io/yaoyi/pen/xxbXJY )
Since you are a real programmer don't start with garbage on the web journey, start with something good.

[jmcilhinney]

I concur on Ajax calls but how will be about if you are using the standard listbox of asp.net? It will still make postbacks...Maybe? Have been years but let me tell you it will still sprout ugly unnecessarily code on the page. In general if the directive is runat="server" it is a server control so I think it will do postbacks.

I was assuming that, in this day and age, the project would not be using Web Forms. If it is then shame on Shaggy for that.

[sapator]

Lol. Fair enough but I would not start bashing Shaggy immediately. We too have old asp.net web apps that we maintain....But if he has the option to start fresh then , yes, shame shame shame! :P

[jmcilhinney]

Lol. Fair enough but I would not start bashing Shaggy immediately. We too have old asp.net web apps that we maintain....But if he has the option to start fresh then , yes, shame shame shame! :P

I guess I was assuming that it was a new project but you're right that that may not be the case.

[Shaggy Hiker]

It's not that far off. The project is specifically about replacing a Web Forms project.

I haven't really explored my control options sufficiently, at this time. One thing at my disposal is a DevExpress subscription. I'll be using one control from them already, because the users really like the functionality of it (though I'll be using the ASP.NET Core version, not the Web Forms version). I know they have listbox controls and similar things, I just haven't taken a serious look at them, yet. First, I need to have some discussions about trimming down the filtering capabilities. Currently, people can filter on some fields that I think are utterly absurd. They'd certainly filter things..usually down to zero results. People would have to type in fairly arbitrary strings and have them precisely match whatever was in the database. That can't be a good idea, especially when there are clearly superior options already available to get the same results.

I guess I do kind of need to figure out the controls I'll be using to be certain what my options are. That does give me a bit more guidance as to what I need to look at, though.

[Shaggy Hiker]

I've been working on this more, and thinking about it more. I'm not quite sure that AJAX will be enough of a solution, and there may not be enough of a solution.

Having looked at what I need to do a bit more, it looks like there are roughly 19 (if I can convince people to jettison a few) pic lists. Selecting in any one list would drop the options in the remaining lists. Some are more discriminating than others, but all can be somewhat discriminating.

That seems like an issue, to me. If a selection in any list can reduce the options in ALL the other lists, then I'm practically doing a full page refresh on any choice, like it or not. There are a few other controls on the form that can also change the options in the pic lists, but which will not themselves be changed by selections made in the pic lists.

In other words, any selection made in a pic list will alter roughly 19 out of two dozen controls on the page. That's pretty close to a clean sweep, so it seems like AJAX wouldn't help, as virtually all the controls get refreshed on any selection.

Am I thinking about this right? AJAX is an asynchronous process, so it might be that all 19 lists could refresh 'simultaneously', but I'd still be refreshing darn near everything. Since each refresh would mean a DB query, would I gain all that much? I don't have a feel for that.

[jmcilhinney]

You could make multiple AJAX calls - one for each control that needs to change - or one call for all the changed data. Depending on how you set it up, you may be just pulling back JSON that contains only the list items, so that's still going to be lighter than pulling back a whole HTML page. Of course, pulling the whole page may not be an onerous task anyway, but I would suggest that AJAX calls in such situations still lead to a better UX because they result in more of a native app type experience, where the contents of a list changes but you don't see a whole page disappear and then reappear, possibly not scrolled to where you were before.

[sapator]

I don't know the architecture but I think of any modern website. They are not refreshing a page. You can do a page refresh it will be programmatically easier as it will bring everything again but you will be bloating the server and stalling your web page. I wish that question was asked a couple of years ago as I could show you what a JS call brings to the page and what a traditional load bring to the page. In most case it's 1/10 and less from what I recall.
So if that is not a professional project , well, ye, you can do a page load , if it's more of the professional side, don't even use MS just go with JS frameworks.

[jdelano]

To me, this project screams Blazor. https://www.dotnettricks.com/learn/b...r-with-dotnet8

EDIT:
I just came across a Visual Studio Live YouTube Video where they demo'd this https://github.com/riganti/dotvvm?tab=readme-ov-file it came to be back in 2014, so it kind of has a Webforms kind of feel but is a true MVVM with instant updating to the model (server-side) from the client browser. It also has a cool trick in that it can coexist with old webforms apps giving you the ability to slowly replace each form and bring the project forward. (around the 37:30 time stamp)

[Shaggy Hiker]

You could make multiple AJAX calls - one for each control that needs to change - or one call for all the changed data. Depending on how you set it up, you may be just pulling back JSON that contains only the list items, so that's still going to be lighter than pulling back a whole HTML page. Of course, pulling the whole page may not be an onerous task anyway, but I would suggest that AJAX calls in such situations still lead to a better UX because they result in more of a native app type experience, where the contents of a list changes but you don't see a whole page disappear and then reappear, possibly not scrolled to where you were before.

That's a very solid point. I was thinking that all the queries that would have to run would be an issue, but they probably would not. The queries would be trivial...well, MOST of them would be trivial, two of them would be vexxingly large. I really need to do some testing on this to try it out. Unfortunately, life has gotten in the way, and I may not be able to get back to it until the end of next week.

[Shaggy Hiker]

I don't know the architecture but I think of any modern website. They are not refreshing a page. You can do a page refresh it will be programmatically easier as it will bring everything again but you will be bloating the server and stalling your web page. I wish that question was asked a couple of years ago as I could show you what a JS call brings to the page and what a traditional load bring to the page. In most case it's 1/10 and less from what I recall.
So if that is not a professional project , well, ye, you can do a page load , if it's more of the professional side, don't even use MS just go with JS frameworks.

In this case, I'm replacing a system that didn't refresh anything. No page, no lists, nothing. The user made their choices in whatever lists they wanted. That either returned something or it returned nothing. People were fine with the behavior, I just feel that it can be done better. It can certainly be done more modern.

[Shaggy Hiker]

To me, this project screams Blazor. https://www.dotnettricks.com/learn/b...r-with-dotnet8

EDIT:
I just came across a Visual Studio Live YouTube Video where they demo'd this https://github.com/riganti/dotvvm?tab=readme-ov-file it came to be back in 2014, so it kind of has a Webforms kind of feel but is a true MVVM with instant updating to the model (server-side) from the client browser. It also has a cool trick in that it can coexist with old webforms apps giving you the ability to slowly replace each form and bring the project forward. (around the 37:30 time stamp)

I'll certainly look into that. I always wanted to try a bit of Blazor.