I understand what you mean. jqGrid has now both simple search and advanced search (an additional configuration parameter). One can add one more parameter for "complex search". If's not a problem. But in my current project the user interface is role based. There are some advanced user which have to analyse data and produce different custom reports or custom filtering of data. This advanced users are from management and so are very important. They know excel very good, so currently I implemented an export of data to excel. But such advanced users like advanced search and they asked me about "complex search". They asked moreover about the possibility to save a complex search request to be able easy reproduce there. So they wanted even more as we currently discuss.

So squid, generally I don't think, that all jqGrids must have "complex search", but some from there. It's realy depend on the project requirements. Currenly I use everyware advanced search because the first look of the dialog is very clear and a simple user can understand imediately how to make a simple search. Only it he is not quite a simple user he begins to try all possibilities. So in general I like a simple user interface, but sometimes one can combine a simple first look with a powerful features.

But it's only my personal opinion. It would be interesting if more peoples say your meaning about the discussed subject.

Best regards and thank you very much squid for your post

Oleg

It is a very good idea! Some time before I wanted to write a suggestion to add possibility to include "all"/"any" not to the full serach request, but to a group instead. I forget to do this because of other main work. The current implementation of parsing of the search requests from the server side can be very easy modified to process such requests and the Advance Search will be perfect. One will be able construct practicaly any serach filter. One needs only to be able to group some filters and place "all"/"any" (AND/OR) for the group. It seems to me it is the same (or almost the same) what you want to implement.

If you will have a beta version of this I could help to test it.

Best regards
Oleg

Yes this have sence, and I hope to work on this in the near future. Moreover I want to go a little deeper - I want to add a addtional column  (the SQL equivalent of AND/OR) which will describe how to apply the rule after every field - i.e

field1 -> operationX -> value ->AND/OR

field2 -> operationY -> value ->AND/OR

...

Best Regards

Tony

If would be fine if the code from the Search Dialog will be share the code which construct edit fields in form edit dialog or the code from inline editing. If one do this, Search Dialog will support more data types like check boxes. Moreover if one define in the editrules, that some field is for example integer, then this rule will not used in the search dialog and the user can input any value in the field for searching. Other editrules can be also helpful for searching. If one define a custom rule with a testing for RegEx for an edit field, the same rule should be used for searching as for editing (at least for "equal to" operation). It will be enough just to use checkValues function from grid.common.js to verify the input values.