Hi,
In the examples so far that I have seen in project tracker - most of the examples show data grids and readonlylistbase objects that go and get the entire data within a table and so in the Data Access Region, the private class Criteria has a comment 'no criteria- we retrive all ...' and is otherwise codeless.
When you select an item in the grid- it of course uses the id of the selected item as a criteria in the class representing the selected items to select,update ,delete etc.
But what about when on a datagrid you want to have one or more selection criteria from the very beginning that brings back a subset of data in the grid? This is obviously more efficient from a design perspective because on any typical transactional data you want to always subset the data. I have a series of dropdown lists where I want to specify the filtering criteria before the data is fetched. I noticed that some grids available out there allow you to filter once fetched which is also useful, but in this case I want the efficiencies mentioned above
Does any one have code examples of doing that? Does the private criteria class in the readonlylistbase object have entries for each item that you eventually want to use as a filtering item? Are these then used in the data portal fetch command in the parameters.addwithvalue items?
Sorry if the answer is patently obvious :(
The answer is obvious - but I don't think I can get a patent on it. <g>
I use search forms where the user can choose some or all of the various criteria on the form.
The left hand column is a check box saying that they want to include that particular criteria. (I check it for the user if they type something in the text box or pick a radio button or cbo.)
The form is bound to a Root BO whose sole function is to gather up the data and pass itself to the ROC as the criteria. The Root BO has rules which can be validated prior to making the call - like at least one of the checkboxes is checked.
So an overload of your ROC criteria class takes 1 parameter of Type "SearchFormBO" (or whatever you decide to call your BO that gathers up your dropdown info.) This is then sent through the DataPortal where you now have access to everything the user chose (or didn't choose.)
Based on this BO it is trivial to build a filter which can be passed to your SQL as part of the WHERE clause.
Joe
;-D
Thanks,
I got one criteria working with one dropdown using the criteriaclass in the root BO.
I am assuming I can specify multiple criteria then in that criteriaclass, based on additional dropdowns etc? (ie about to try that next ...)
Nope. You missed what I was saying.
You do not use a criteira class inside a Root BO.
The Root BO itself is the criteria for your search screen.
e.g. call it MySearchBO.
Then it will contain Properties for your dropdowns. Plus any rules you want.
Just has a DP_Create and nothing else as you will not be saving this BO to your DB.
Then your ROC has a factory method like this:
GetMyList(mySearchBO as MySearchBO) As MyList
Then in DP_Fetch of your ROC you parse the contents of mySearchBO to build a WHERE clause to fetch your ROC.
Joe
So if I understand correctly,
in effect you create a business object for the marshalling/identification of the search criteria itself, then use its results to build the where clause.
Yes.
Again - it is a very scaled down BO.
It can be used for binding (and unbinding) the search form data.
Then it is passed to the ROC as shown above.
Joe
Copyright (c) Marimer LLC