locked
common pattern - show all first, then filter - linqdatasource control RRS feed

  • Question

  • User-929021816 posted

    Hello,

    A very common setup is to first show all data and have user input controls for users to optionally filter the data. I'm using a linqdatasource control and I'm not sure how I should be going about making this scenario work? For example, using a linqdatasource control, a gridview or listview to show the data, and a dropdown listbox for a user control to filter, I can add a 'control parameter' to the linqdatasource and tie it to that dropdown list box, but this setup forces the user to select a filter *before* showing any data, not the scenario I want. I want to show all data first.

    what am I supposed to do? For clarity just imagine we are talking about products and product categories. I want to first show all products when the page first loads and have a dropdown list box populated with product categories that a user may optionally select to filter the product list by that selected category.

    Sunday, January 23, 2011 12:50 PM

Answers

  • User626880745 posted

    With the LinqDataSource you can set the AutoGenerateWhereClause property - the LDS will dynamically create the Where clause from the parameters in the WhereParameters.

    You could so set up your DropDownList as a ControlParameter with ConvertEmptyStringToNull="true" (and have a ListItem set to Value="" - you could insert that ListItem dynamically in the DataBound event)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, January 24, 2011 9:24 AM
  • User626880745 posted

    1. Yes

    2a. They would be used be used with a wildcard (you'd still have to set the ConvertEmptyStringToNull="false")

    2b. you could project and assign to e.Result in the Selecting event


    Alternatively, and especially if the requirement goes towards a good amount of customization, you could do without a LDS.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, January 24, 2011 3:49 PM

All replies

  • User626880745 posted

    With the LinqDataSource you can set the AutoGenerateWhereClause property - the LDS will dynamically create the Where clause from the parameters in the WhereParameters.

    You could so set up your DropDownList as a ControlParameter with ConvertEmptyStringToNull="true" (and have a ListItem set to Value="" - you could insert that ListItem dynamically in the DataBound event)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, January 24, 2011 9:24 AM
  • User-929021816 posted

    Hi PeteNet. Ok, I think I understand your suggestion, is this correct: Because the AutoGenerateWhereClause will automatically create the where clause for all parameters in the parameters collection, and if a parameter has no value assigned, it will not be used, what will happen is that with using ConvertEmtpyStringToNull and the default listItem's value being an empty string, it will not be used an return all values... then as soon as you actually select something from the list that is not an empty string value, the parameter will be used.

    1. is my understanding correct on that?

    2. assuming I do undertand that correctly, the AutoGenerateWhereClause has some limitations in that it only uses 'AND' when combining multiple parameters and the comparison must be equality. So, for the specific example I gave, I realize that's fine and this is a great solution. However, thinking ahead, what about solving this same issue when there will be multiple parameters and using both 'AND' and 'OR' may be necessary, or just using a comparison operator other than equality? 

    2a. if I were to assign the where property myself using named parameter placeholders, what would happen if I simply did not assign any value to some or all of the named parameters? Would they still be used with null values or would they not be used at all like with AutoGenerateWhereClause?

    2b. the only other possibility that came to mind was using a complete separate LDS... one to return all records that gets used only on the initial load of the page, then a different one for when a search/filter is done by the user... I assume that could be made to work but it doesn't sound like a good idea... clunky.

    Monday, January 24, 2011 12:50 PM
  • User626880745 posted

    1. Yes

    2a. They would be used be used with a wildcard (you'd still have to set the ConvertEmptyStringToNull="false")

    2b. you could project and assign to e.Result in the Selecting event


    Alternatively, and especially if the requirement goes towards a good amount of customization, you could do without a LDS.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, January 24, 2011 3:49 PM
  • User-929021816 posted

    thanks PeteNet

    Monday, January 24, 2011 5:07 PM
  • User-929021816 posted

    Hi PeteNet,

    I just re-read this and I'm wondering about '2a'. "They would be used with a wildcard"... are you only referring to scenarios where strings are used, or specifically using .contains() as the condition? I'm wondering what would happen if I assigned the 'where' property something like: "(someStringField == @param1 && someIntegerField > @param2) || someOtherField.Contains('yadayada')"

    then in code behind, depending on user input, either all or only some of the parameters actually get values assigned... what would happen? the LDS would have 3 params in it's whereParameterCollection but some would have no value assigned?

     

    Tuesday, January 25, 2011 5:06 PM