GetListItems: Performing a comprehensive user-defined CAMLQuery

Apr 25, 2011 at 3:55 PM

Me again. You may remember the question from my previous discussion posted on here, and I now have another.

The overall project is a simple concept: Take information from SharePoint's XML (using SPServices' GetListItems), assign each attribute to a formatted variable, then slap it all into respective elements in a CEWP. Voila, a highly-customizable front end for detailed information submitted via simple InfoPath forms. That part is working beautifully.

The part that isn't working beautifully (yet) is a very specific requirement for searching through this data. After using InfoPath to fill in Custom List columns, the customer wants a search form that allows the user to make selections that filter the list items. Using a used automobile database as an example, the user would like to be able to search for Ford, Toyota, and Honda cars that have a 4 cylinder engine and are painted blue or red. Therefore the information passed to the query would be:

Make: Ford OR Toyota OR Honda
Engine: 4 cylinder
Color: Blue OR Red

Using SharePoint's built-in filtering capabilities is out of the question - multiple filters can't be applied to a single column (like Make or Color in this case), and even if a column is designed to accept multiple selections, a "Leather/Sunroof" filter for an "Options" column would only return vehicles that have both features rather than vehicles that have leather, a sunroof, or both.

Essentially what I'm looking for is a way to give a user a list of selections for multiple-choice columns, allow them to pick several (or one, or none), and display the results using a CONTAINS query rather than an EQ query. Can this be done with SPServices? If not, do you guys have any suggestions as to where to look for such a tool?

Apr 25, 2011 at 4:25 PM

You could use the Contains CAML operator in lieu of Eq. I do this for some of my queries and it works fine. Not sure where you are using SPServices, but it should work. I think you might have some issues trying to guess what may be filtered though. It could be that you would have to build the CAML in pieces based on what your users select.

Apr 25, 2011 at 4:30 PM
Edited Apr 25, 2011 at 4:33 PM
spevilgenius wrote:

It could be that you would have to build the CAML in pieces based on what your users select.

This is what I'm worried about. That would be an awful lot of code - there'd be literally dozens and dozens of combinations for potential search criteria!

I know about using CONTAINS in a CAMLQuery - I actually use it for some of my code - but I'm referring to filtering list data without having to resort to SharePoint's built-in filtering that uses an EQ operator.

Apr 25, 2011 at 5:09 PM

Still not sure what you are referring to when you say built in filtering and an EQ operator. Are you talking about the url filtering that you could do like FilterField1=Make&FilterValue1=Toyota

Coordinator
Apr 25, 2011 at 5:23 PM

First things first, which version of SharePoint are you using, and has the Search service been configured? A lot of what you're asking for can be accomplished in native SharePoint search, especially in 2010. There's some possibility here that you're reinventing the wheel.

If you wanted to go the CAML route, you wouldn't have to program for each and every possible combination, just use logic in your script to build it. Your logic would have to detect if the user selected more than one make (simple to do with jQuery), then add the contains logic for each one they selected. Don't hardcode the options, pull the selected values from the checkboxes (or whatever field type you're using). Certainly your logic would be pretty complex, as it'd need to be able to nest multiple CONTAINS params with the necessary logic between them, but it's certainly do-able, and wouldn't require you to script every possible combination.

Potentially, you could also automate portions of the form, so for example, the user would only be presented manufacturers to pick from if there's a record for that manufacturer in the list. You'd just fire SPServices to get all of the records in the list, parse through the manufacturers, and add a checkbox on your form for each unique entry.

This certainly can be done with SPServices; SPServices would call the query, but you'd need to write your own logic to build the CAMLQuery variable, then pass that to SPServices. Make sense?

This should be "relatively" easy to put together, though looping back to my first question; if you have search configured, you have the ability to filter search results based on meta data out of the box.

Apr 25, 2011 at 5:23 PM
spevilgenius wrote:

Still not sure what you are referring to when you say built in filtering and an EQ operator. Are you talking about the url filtering that you could do like FilterField1=Make&FilterValue1=Toyota

Correct. Filtering using the column dropdowns on a list view web part or just building the URL manually. Completely inadequate for this application.

Coordinator
Apr 25, 2011 at 5:25 PM

I think we posted at the same time; see my reply above. 

Apr 25, 2011 at 7:05 PM
webdes03 wrote:

I think we posted at the same time; see my reply above. 

Indeed, I was about to reply when I got called away for a meeting.

webdes03 wrote:

First things first, which version of SharePoint are you using, and has the Search service been configured? A lot of what you're asking for can be accomplished in native SharePoint search, especially in 2010. There's some possibility here that you're reinventing the wheel.

If you wanted to go the CAML route, you wouldn't have to program for each and every possible combination, just use logic in your script to build it. Your logic would have to detect if the user selected more than one make (simple to do with jQuery), then add the contains logic for each one they selected. Don't hardcode the options, pull the selected values from the checkboxes (or whatever field type you're using). Certainly your logic would be pretty complex, as it'd need to be able to nest multiple CONTAINS params with the necessary logic between them, but it's certainly do-able, and wouldn't require you to script every possible combination.

Potentially, you could also automate portions of the form, so for example, the user would only be presented manufacturers to pick from if there's a record for that manufacturer in the list. You'd just fire SPServices to get all of the records in the list, parse through the manufacturers, and add a checkbox on your form for each unique entry.

This certainly can be done with SPServices; SPServices would call the query, but you'd need to write your own logic to build the CAMLQuery variable, then pass that to SPServices. Make sense?

This should be "relatively" easy to put together, though looping back to my first question; if you have search configured, you have the ability to filter search results based on meta data out of the box.

Unfortunately, we are running 2007 with no foreseeable timeline for a 2010 introduction. Cost-benefit analysis in a government setting is always a painstakingly slow process, especially when those performing the analysis don't even know what SharePoint is. Search is configured, but unreliable and slow, and I have no way to customize the results - I would need the results to point to a separate list item, as the InfoPath forms aren't the desired method for displaying the data - rather the Web Part Pages that are configured to pull the data from the XML and style it for display. Duplicating the column information from the InfoPath forms for the Web Part Pages would be needlessly complicated. My intention would be to setup a Hyperlink column in the InfoPath forms, manually insert the Web Part Page's link, and use that as the search result.

If the only solution had been programming for each possibility I wouldn't have done it. I'm thinking that checkboxes will be the way I'll go - the biggest part of my question was just whether it could be done. As I stated in my other discussion, I'm no expert on JavaScript and am having to steal a lot of code (and ask a lot of questions, obviously) in order to make this project work.

Coordinator
Apr 25, 2011 at 7:51 PM
Edited Apr 25, 2011 at 7:51 PM

With respect to the search stuff, you certainly can customize the way those results are returned. Search results are typically pushed through some XSL templates, so you could customize a template for your specific site/search web part. That said, if the search isn't setup, configured, or working well, it's probably not a source you can really rely on here. The results are only as good as the index (and how often the crawl runs).

Question number one then, how large is this list, and how many filters are we talking about?

I think we've identified that it certainly can be done, the question is just the best route to go about it. If you create a basic HTML form, you can use jQuery to do all of the analysis on which items the user has selected so that everything can be done without a postback (that'd be the way I'd do it anyway). User completes selection, clicks "Search" button (or whatever it's called), jQuery listener on the button detects the click, looks at all of the form values to see what's selected, builds the CAMLQuery, passes query to SPServices, and data get's appended to a table. It'd be difficult to help you with any of the logic without seeing more of what you're trying to do. I'd assume that it's probably fairly unique to your solution so I'm not sure how much code reuse you'd find; though we can certainly help discuss the logic and proof anything you come up with should you have issues.

Oh, and I totally feel your pain with government; I previously worked for a defense contractor... :-)

Apr 25, 2011 at 8:12 PM
webdes03 wrote:

With respect to the search stuff, you certainly can customize the way those results are returned. Search results are typically pushed through some XSL templates, so you could customize a template for your specific site/search web part. That said, if the search isn't setup, configured, or working well, it's probably not a source you can really rely on here. The results are only as good as the index (and how often the crawl runs).

I'd love to see some examples of customized search results. Do you know of any off-hand? I'd really like to try my hand at some XSL, especially if SharePoint's built-in search will take care of most of the difficult coding.

webdes03 wrote:

Question number one then, how large is this list, and how many filters are we talking about?

There would be two lists, each with around 30 columns and 30-40 items, with the possibility of expanding to several dozen more items. If the boss likes this tool enough, he may want to pull in more information.

Many of these columns use text input boxes for their information and several would not be feasible for a search. I would hazard a guess that no more than 10 columns would be searchable with this tool.

webdes03 wrote:

I think we've identified that it certainly can be done, the question is just the best route to go about it. If you create a basic HTML form, you can use jQuery to do all of the analysis on which items the user has selected so that everything can be done without a postback (that'd be the way I'd do it anyway). User completes selection, clicks "Search" button (or whatever it's called), jQuery listener on the button detects the click, looks at all of the form values to see what's selected, builds the CAMLQuery, passes query to SPServices, and data get's appended to a table. It'd be difficult to help you with any of the logic without seeing more of what you're trying to do. I'd assume that it's probably fairly unique to your solution so I'm not sure how much code reuse you'd find; though we can certainly help discuss the logic and proof anything you come up with should you have issues.

This is pretty much exactly what I'd be looking to do, and exactly how I'd imagined it would go. I will likely be working on putting this together over the next few days, as well as looking into customizing SharePoint's built-in search. The cave-dwellers in charge of maintaining the SharePoint server swear up and down that they've fixed the indexing (it used to go on for so long that the next scheduled index would start before the first finished, therefore slowing down the first one so much that the THIRD would start, and exponentially slowing the rest down until it got up to EIGHT) and I've noticed that the search results are more reliable.

webdes03 wrote:

Oh, and I totally feel your pain with government; I previously worked for a defense contractor... :-)

If only it was temporary. Working in this circus is my full-time job.

Coordinator
Apr 25, 2011 at 8:23 PM
Edited Apr 25, 2011 at 8:24 PM

Once you've put up with a government contractor for a couple years, you can handle even the most underdeveloped clients ;-)

As you pointed out, the only columns you'll be able to accurately filter/query against are those that are lookups, choices, etc. Anything that's free form text just isn't going to be consistent enough.

Off the top of my head, you can try this post for search customization, though I'm sure there's lots of blog posts on the topic. This is a very basic example, but you can basically change any of the XSL.

It sounds like the search may be slightly underpowered. I've certainly seen scenarios where it takes 18-20 hours for a full crawl (for indexes containing lots of data; millions of records), but they should be able to do a full crawl on say the weekends, and run an incremental each evening or whatever. If they're redoing the full crawl every time then that might be one of the issues.

With 30-40 items it's not a big deal, but if we were talking hundreds or thousands I'd also suggest indexing select columns of the list to aid with performance, but with that small of a list you're not going to see much benefit from that.

Apr 25, 2011 at 8:26 PM

I am right there with you! I work for a shipyard full time and we just have WSS only. I have not really been asked to create this miracle yet, but it may happen. I am curious as to why Infopath forms were used. Nothing against it, just curious. I like the idea of building a jQuery type search though.

Apr 26, 2011 at 5:34 PM
Edited Apr 26, 2011 at 7:39 PM

All right, here goes. Like I said I'm terribly new at this, so if this mess (and I know it's a mess) is completely off-target and there are any helpful resources you might be able to suggest, please let me know. Posting this here is really embarrassing, but feel free to poke fun if it means you'll give it a good look-over!

 

<script language="javascript" type="text/javascript">

function getResults() {
for (Count=0;Count<7;Count++) {
if (document.forms[Count].Employment Level.checked) {
var queryString = + "<And><Contains><FieldRef Name='" +  document.forms[Count].Employment Level.name + "'/><Value Type='Text'>" + 
document.forms[Count].Employment Level.value + "</Value></Contains></And>" } } $().SPServices({ operation: "GetListItems", async: false, listName: "SBUpdateII", CAMLQuery: "<Query><Where><And>" + queryString + "</And></Where></Query>", completefunc: function (xData, Status) { $(xData.responseXML).find("[nodeName=z:row]").each(function() { var resultList = "<li>" + $(this).attr("ows_Nomenclature") + "</li>"; $("#resultsUL").append(resultList); }); } }); } </script> <form name="searchPlatforms">Level of Employment:<br /> <label><input type="checkbox" name="Employment Level" value="National/Strategic"> National/Strategic</label><br /> <label><input type="checkbox" name="Employment Level" value="Theater/Operational"> Theater/Operational</label><br /> <label><input type="checkbox" name="Employment Level" value="Tactical"> Tactical</label><br /> <br /> Operational Realm:<br /> <label><input type="checkbox" name="Operational Realm" value="High Altitude"> High Altitude</label><br /> <label><input type="checkbox" name="Operational Realm" value="Medium Altitude"> Medium Altitude</label><br /> <label><input type="checkbox" name="Operational Realm" value="Low Altitude"> Low Altitude</label><br /> <label><input type="checkbox" name="Operational Realm" value="Surface"> Surface</label><br /> <br /> <input type="submit" value="Search!" onClick="getResults(this.form)"> </form> <div> <ul id="resultsUL"> </ul> </div>

 

I can only imagine that there are tons of problems with this code and would totally understand if you guys would rather point me towards an Intro to JavaScript lesson, but if you're willing to help I'd be thrilled. I already know there are some serious errors, but I'm afraid I don't know exactly how to fix them. I may have the CAML query syntax built wrong, but due to proxy errors on our network the Microsoft MSDN site is blocked so I can't pull up their reference material that I've been using.

As an aside - since the CEWP doesn't support <FORM> elements, can this be run from a Page Viewer web part without causing issues with the SPServices library?

Coordinator
Apr 26, 2011 at 6:02 PM
Edited Apr 26, 2011 at 6:04 PM

So you can have all of the form elements you want, just not a "form" tag. You can save this file as searchform.txt as an example, store it in a document library and use a CEWP to render it. You could also put this markup in the page using SPD, you just can't have a form tag. This is a result of the entire SharePoint page being a giant form. It's not necessarily the fact that you're using a CEWP that's the issue, you couldn't put a form tag in the middle of any page.

The workaround is to just drop the form tags, and instead of using a submit button referencing the form, use jQuery to pull in the values. My personal advise, if you're loading jQuery already (which you are to use SPServices), you might as well take advantage of that and use jQuery to help you though some of this.

As an example, you can create a button like this:

<input type="button" value="Search" id="searchButton"/>

And bind a function to it like this:

$("#searchButton").click(function() {
  alert ('search button clicked');
  // put your script here that you want to execute after button click.
});

You can put your logic to build your CAML in there, and the SPServices call. You can also access your fields by ID or name using jQuery, and if you're working with checkboxes you can use the :checked selector in jQuery to bring back any checkboxes that are checked.

For example, if you wanted to get the value of a text input field with an ID of "textField" you could do this:

$("#textField").val();

You're certainly on the right track, but again I think some of the jQuery will help you. Have a look here for information on the :checked selector.

The only potential issue I see with your CAML is that you've got <And></And> in your SPServices call, and you're writing the "And's" in the logic. I believe your CAMLQuery reference in the SPServices call should be "<Query><Where>" + queryString + "</Where></Query>". As you have it now, you're going to end up with "<And><And>" as an example.

Apr 26, 2011 at 7:27 PM
Edited Apr 26, 2011 at 7:29 PM

So much great info. Thanks, webdes03. Here's what I have so far after redoing most everything in jQuery. Seems much simpler but the variable queryString ends up undefined no matter what I check:

 

<script language="javascript" type="text/javascript">

$(document).ready(function() {
 var queryString
 $("#searchButton").click(function() {
   $("#platformForm").find("input:checked").each(function() {
   var queryString = queryString + "<Contains><FieldRef Name='" + $(this).attr("name") + "'/><Value Type='Text'>" + $(this).attr("value") + "</Value></Contains>"
  });
  $().SPServices({
   operation: "GetListItems",
   async: false,
   listName: "SBUpdateII",
   CAMLQuery: "<Query><Where><And>" + queryString + "</And></Where></Query>",
   completefunc: function (xData, Status) {
    $(xData.responseXML).find("[nodeName=z:row]").each(function() {
     var resultList = "<li>" + $(this).attr("ows_Nomenclature") + "</li>"
 	 $("#resultsUL").append(resultList)
    });
   }
  });
  alert ("Value of queryString: " + queryString);
 });
});
 
</script>

<div id="platformForm">
 INT:<br />
 <label>
  <input type="checkbox" name="INT" value="IMINT" /> IMINT
 </label><br />
 <label>
  <input type="checkbox" name="INT" value="MASINT" /> MASINT
 </label><br />
 <label>
  <input type="checkbox" name="INT" value="FISINT" /> FISINT
 </label><br />
 <br />
 Operational Realm:<br />
 <label>
  <input type="checkbox" name="Operational Realm" value="High Altitude" /> High Altitude
 </label><br />
 <label>
  <input type="checkbox" name="Operational Realm" value="Medium Altitude" /> Medium Altitude
 </label><br />
 <label>
  <input type="checkbox" name="Operational Realm" value="Low Altitude" /> Low Altitude
 </label><br />
 <label>
  <input type="checkbox" name="Operational Realm" value="Surface" /> Surface
 </label><br />
 <br />
 <input type="button" value="Search" id="searchButton" />
</div>

<div>
 <ul id="resultsUL">
 </ul>
</div>

I must be missing something easy here, or maybe .find("input:checked") isn't working the way I think it should. Apologies for changing one of the columns.

Coordinator
Apr 26, 2011 at 8:08 PM
Edited Apr 26, 2011 at 8:09 PM

I'm thinking it might be the jQuery selector blowing up because it's searching inside the platformForm div. Add an alert into the each() so we can see if it's firing; that'll tell us if the selector is bad or something else.

$("#platformForm").find("input:checked").each(function() {
  alert('found input');

That should prompt you with an alert for each check box that's checked.

If that doesn't work, try changing your selector to this...

$("#platformForm input:checked").each(function() {

My guess is that the "find" isn't working, but the line above should fix that.

Apr 26, 2011 at 8:33 PM

Is there a reason to redeclare the var queryString in your .each function? I thought that it would just reset your variable each time.

Coordinator
Apr 26, 2011 at 9:09 PM
spevilgenius wrote:

Is there a reason to redeclare the var queryString in your .each function? I thought that it would just reset your variable each time.

That's another valid point. I don't think that's the sole issue; I didn't even notice that because I was focused on the selector.

The queryString variable is defined at the top of the script, so this line:

var queryString = queryString + "<Contains><FieldRef Name='" + $(this).attr("name") + "'/><Value Type='Text'>" + $(this).attr("value") + "</Value></Contains>"

Should become this (removing the extra var declaration):

queryString = queryString + "<Contains><FieldRef Name='" + $(this).attr("name") + "'/><Value Type='Text'>" + $(this).attr("value") + "</Value></Contains>";
Coordinator
Apr 26, 2011 at 9:11 PM

There are also a number of line-terminating semicolons missing. There are times when you can get away with that, but I'd suggest getting them all in there.

M.

Apr 27, 2011 at 12:56 PM

Success! Thanks to everyone's fixes it appears this tool is now working. All I have to do is change the .append() method so that it's not simply adding the results over and over again as the user changes his or her search.

<script language="javascript" type="text/javascript">

$(document).ready(function() {
 $("#searchButton").click(function() {
  var queryString = "<Query><Where><And>";
  $("#platformForm").find("input:checked").each(function() {
   queryString = queryString + "<Contains><FieldRef Name='" + $(this).attr("name") + "'/><Value Type='Text'>" + $(this).attr("value") + "</Value></Contains>";
  });
  $().SPServices({
   operation: "GetListItems",
   async: false,
   listName: "SBUpdateII",
   CAMLQuery: queryString + "</And></Where></Query>",
   completefunc: function (xData, Status) {
    $(xData.responseXML).find("[nodeName=z:row]").each(function() {
     var resultList = "<li>" + $(this).attr("ows_Nomenclature") + "</li>";
 	 $("#resultsUL").append(resultList);
    });
   }
  });
  alert ("Value of queryString: " + queryString);
 });
});
 
</script>

Another issue to work around: The <And> element in a CAML Query can only be used if there is more than one value to query against. For example, the following will not work:

<Query><Where><And><Contains><Field Ref Name='INT'/><Value Type='Text'>IMINT</Value></Contains></And></Where></Query>
So I'll need a way to figure out if only one input is checked, and to parse the variable to replace <And> and </And> with "". Would this be the right way to go?

Coordinator
Apr 27, 2011 at 1:00 PM

If you look at how I build up the queries in SPServices in the SPCascadeDropdowns and SPShowRelatedInfo functions, you can see how I go about doing this. Basically, I build it all up variably based on what the user has asked for. CAML's odd structure actually lends itself to this "building up" method better than some other languages I've used.

M.

Apr 27, 2011 at 1:18 PM

Well, I put this together which actually works quite well:

<script language="javascript" type="text/javascript">

$(document).ready(function() {
 $("#searchButton").click(function() {
  var queryString = "<Query><Where><And>";
  var checkedCount = 0;
  $("#platformForm").find("input:checked").each(function() {
   checkedCount++;
   queryString = queryString + "<Contains><FieldRef Name='" + $(this).attr("name") + "'/><Value Type='Text'>" + $(this).attr("value") + "</Value></Contains>";
  });
  if (checkedCount == 1) {
   queryString = queryString.replace(/<And>/,"");
   checkedCount = "";
  } else {
   checkedCount = "</And>";
  }
  $().SPServices({
   operation: "GetListItems",
   async: false,
   listName: "SBUpdateII",
   CAMLQuery: queryString + checkedCount + "</Where></Query>",
   completefunc: function (xData, Status) {
    $(xData.responseXML).find("[nodeName=z:row]").each(function() {
     var resultList = "<li>" + $(this).attr("ows_Nomenclature") + "</li>";
 	 $("#resultsUL").append(resultList);
    });
   }
  });
  alert ("Value of queryString: " + queryString);
 });
});
 
</script>

It's not pretty, but it works. Hopefully I can use this to fine-tune the presentation.

Related to this, I just found out that you have to use SharePoint's _x0020_ for spaces in column names. "Op Realm" in a CAMLQuery needs to be "Op_x0020_Realm" which was causing some issues with my results. That was probably somewhere on this site that I just didn't see.

Coordinator
Apr 27, 2011 at 1:28 PM

That's the StaticName of the column. All columns have a StaticName and a DisplayName. This is SharePoint, not SPServices.

Note: You should always enclose z:row (or any other literal) in quotes: find("[nodeName='z:row']").

M.

Apr 27, 2011 at 1:58 PM
sympmarc wrote:

That's the StaticName of the column. All columns have a StaticName and a DisplayName. This is SharePoint, not SPServices.

Note: You should always enclose z:row (or any other literal) in quotes: find("[nodeName='z:row']").

M.

Right, I've looked at the XML output for the lists, which has helped immensely. I downloaded the CAML Viewer by Stramit here on codeplex, which also helped a ton.

I'll make the change to z:row right now. Thanks for helping me to clean up my obviously messy code.

Apr 28, 2011 at 2:34 PM
Edited Apr 28, 2011 at 2:37 PM

Another snafu: CAML only allows a comparison of two items in a single <And> element. This means my syntax works for 1 or 2 items, but not for 3 or more - I'll have to nest <And> elements. This code is going to get ugly.

I'm about to start determining the logic to make this work, but before I do does anyone have any recommendations? It's going to be a gigantic pain in the rear to set up all the different ways my Query string will have to be constructed in order to avoid errors.

Coordinator
Apr 28, 2011 at 2:37 PM

Let's take a little step back. I wonder if this isn't a better candidate for a DVWP? Can you restate your goals, now that you've been working on it a bit?

M.

Apr 28, 2011 at 2:51 PM
Edited Apr 28, 2011 at 2:53 PM
sympmarc wrote:

Let's take a little step back. I wonder if this isn't a better candidate for a DVWP? Can you restate your goals, now that you've been working on it a bit?

M.

I have zero access to Designer. Our benevolent SharePoint Server Gods consider us too simple-minded to utilize it and therefore forbid it.

I'll give you about as direct an outline as I can for the goal of this project:

  • A table consisting of checkboxes corresponding to column selections for a list, just like how I've put together the small forms in the above code examples.
  • The checked selections would pass to some kind of query, returning a list of matching list items according to the column choices that are checked.
  • Multiple choices must be supported, and the ability to set the "display" of the search results is necessary. The reason for this is because the actual list item is not the intended destination, but rather a hyperlink column set up for the list that will direct the user elsewhere to a related item in another list.

The general idea is to provide a list of choices - not including the ability to type in search criteria - that allow a quick way to narrow down a list. Hopefully this makes sense. If you need more information, please let me know.

Coordinator
Apr 28, 2011 at 2:56 PM

I wonder if a better answer isn't something more like Jaap Vossers' Instant List Filter. In other words, rather than trying to request items as the selection is made, show all the items in a normal LVWP and simply filter them down based on the selections.

It might be easier to build and also a better UX?

M.

Apr 28, 2011 at 3:07 PM
sympmarc wrote:

I wonder if a better answer isn't something more like Jaap Vossers' Instant List Filter. In other words, rather than trying to request items as the selection is made, show all the items in a normal LVWP and simply filter them down based on the selections.

It might be easier to build and also a better UX?

M.

His live demo is blocked pending categorization through our firewall service, and his blog is blocked for being a blog. Working for the government is maddening.

Once the categorization goes through on the live demo site I'll give it a whirl, see if it does what I need it to do. Peter Allen's List and Document Library Filter was one of the first things I found when I started my Google crawl for potential solutions, but it's not quite what I'm looking for.

Coordinator
Apr 28, 2011 at 5:35 PM

Nothing is going to be exactly what you want, it's my guess.

Given the number of items you have, there's no real performance penalty to load everything onto the page and then do the filtering strictly in the DOM. That's going to be more performant than Web Services calls.

M.