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

image

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.

 image

3. Iterate through each row adding the result in to the list

image

The propertyPaths are 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.

2 Comments

  1. So Mark, just looking for direction here. I am already assuming I have to do this in VS (relatively new here, but a quick learner)….

    I have a lookup and a datagrid under it. On the change action of the lookup I want to show the related 1:m items in the grid. From that grid I am going to have to be able to use the SelectedIndex method to retrieve the id and insert some stuff in a seperate table\entity. Kind of like a picker type module. In essense I have two grids, the first one is the one showing the items from the related lookup. The second one is showing the items that were select from the first grid.

    I tried the business rule with the GetMethod property like you said most would try but can not get the refresh portion to work when they select a different lookupid. If I save the record and re-open it is finds itself ok. Ok, I’ll chalk that up to I wish I saw your posting first….

    I look at the requirements, and think.. ok, peice of cake. In the Lan I could have this done in an hour or so. I retrospect I see that it is more difficult in the Web. Yes I know its suppose to be harder but I have been battling this on and off for about a week and got 2-black eyes and a broken keyboard from bashing my head against it…

    So 2 requirements: A dependent grid based on the results from a selected lookup, and the second is being able to select an item out of that first grid and insert that ID into a seperate table\entity.

    All I am looking for is you advise on what direction you would take for this if you were tasked with this kind of scope. Left, right, or pull the eject button and go straight up?

    –Ken–

    1. Ken, I would think the problem is in the placement of the current grid binding when it decides the values to obtain. These grids also can be bound directly to using the DataSource = and DataBind() methods. For what you are looking for I would add some code into the PageLoad method to determine the binding to attach and call it myself in some for such as

      Criteria[] args = new Criteria[] { new Criteria {“Account”, “acdef”}};
      dataGrid1.DataSource = xyz.GetFilteredRowSet(args);
      dataGrid1.DataBind();

      since this would be done in VS I would clear out the old grid bindings workload in favor of a new programmatic load. Does this make sense. Row selection should be somewhat the same. You can look at an existing grid that has been deployed that provides grid support. There will be an method for supporting grid actions within that you can determine the actual selection code to determine if the row is selected. Then the last piece of the puzzle is to be able to do a show of a dialog.

Leave a Reply