Grid Binding with GetByMethod
So lately there have been questions on how do create a filtered datagrid using the Sage SalesLogix web platform. This is a valid question and the coding around it is somewhat trickier then just binding to a simple list data source. In trying to solve the problem most would go to the GetByMethod approach and find that it would not work based on the training sample. I believe that the functionality had changed between the 7.5 and 7.5.1 timeframe and really requires a bit more.
So we are going to do the method slightly different.
1. Create your business rule method as usual choosing to IList as the result out value
2. Write your query code using projection based query. What I mean is that instead of having NHibernate return full entities we want just field values specific to the grids results.
3. Iterate through each row adding the result in to the list
The propertyPaths variable is there to define the fields in the object and their specific order. Order counts so make sure to line list to match your projections. You will be creating a ComponentView object for each row and initializing it with both the property path values and the data for the row.
The business rule itself is done. The final piece of the puzzle is the setting of the EntityType property on the datasource. Since we are not returning a specific entity we need to change this value to return Sage.Platform.ComponentModel.ComponentView instead.
Once this is your custom grid is ready to go.
Custom Filtering
I am not going to give a full sample on this one but to point to what I perceive as right direction. Many SalesLogix web developers still shy away from breaking out visual studio and hand coding a smart part. For some of the more advanced methods of handling this functionality it really is the best solution. GetByMethod is great when you want to handle specific use cases but can be somewhat inflexible due to how the method is bound and invoked in the standard smart part. More specifically starting to add filter parameters in to the mix is not an easy thing to do. Other thoughts are to code several methods and just change them up, however if your query code is to be dynamic and allow users to enter a parameter you still have the problem of passing in extra data.
This is were I would advise breaking out the method, and adding the parameters required to meet the use case. Using a custom smart part I would handle the databinding and calling of the business rule myself removing the extra code/goo that would be generated.
Once the functionality was correctly tested in VS I would remove the old smartpart and import the new one into <portal>\Support Files\SmartParts\<Entity>\ making sure that it was available for deployment.