Initial Sort Order on editable BOs

How do we establish an initial / default sort order on an editable BO in a grid?  Editable BOs only allow us to specify a table name and where condition(s), but no default order.  Most occasions where I'd like the results displayed initially displayed in an editable grid to display in the mostly like display order (client number then matter number for instance).

 

I know we can add an order by clause in query BOs, but this doesn't appear to be an option in an editable BO.

 

BPM 9.0.3.3

Tagged:

Comments

  • I'm not aware of any way to control default sort order for a table BO. I agree that it would be very nice to have.

  • As Ari suggested it would be nice to be able to configure the sort order on a table (editable) business object but currently the way it works is that it will sort by default based on the columns that you configure as a primary key following the order that the columns exist in the table. If there is only one primary key column it will sort alphanumerically by that column. If there are more than one primary key columns it will sort first by the first column in the table and then second by the next and so on.

     

    With this understanding you should be able to setup your table and manipulate the entries in a primary key column to force the output to come out sorted as you so desire.

  • How about creating a database View as another option.  You could control the sorting in the View and set up your table BO to point to the View.  Never tried it but I would think that should work.

     

    Keep in mind, you can also allow the end user to do multi-column sorting now if you set your Grid to allow it.  Of course that doesn't resolve the specific need that you've brought up, which is to set the default sorting, but it may help in case you weren't aware.

  • However, if your primary key is an identify for instance, but you want the BO to sort on non-key values (say client name which is not unique let alone primary) you cannot manipulate the key to get the order desired.

     

    The view is an interesting idea.  I'd hate to have to create a "dummy" DB object just to get around something so basic and serves no other purpose, but perhaps I can give it a test to see if it works.

     

    I know users can reorder the columns, but I am getting a crash every time a user tried to reorder by columns on editable grids when in tab/read mode.  Plus it doesn't present data in the order desired in the first place.

  • Grid is telerik control. Does anyone try to use client side api of this control to sort it properly on form load?

  • Found this workaround in another thread... You can sort an editable grid entirely on the client side if you put the following on form load:

     

    if

    (!$find('grdTimesheet_Editor_ctl00').sort('bofieldname')) returnfalse;

     

    ...where bofieldname is the name of the column you want to sort on.

  • Is this in any supported?

     

    I'm afraid we have enough problems with supported functionality not always working as expected. In our quite extensive experience, such hacks will almost constantly break, I'm afraid.

  • Hi Jerome,

     

    I was answering Greg's specific question as to whether it was possible to do this on the client side. While I personally agree that something like a default sort order on a grid should be an "out-of-the-box" option, there are times when it is simply not possible to meet spec/deadline without exploiting an undocumented feature.

     

    Insofar that all client side javascript is self documenting (by virtue of being cleartext readable), you can find this sort method along with all other client side API in the ...\BPM\Web\scripts\BpmAjaxLibrary.js file.

  • I fully understand.

     

    Unfortunately we often have to deal with systems that have been 'hacked' and customers are not happy to learn that most of these have to be discarded or rewritten. As a suggestion from a Metastorm employee, your suggestion can appear to some to be 'supported'. I believe it is wise always to indicate that this is not supported, and that it will probably need to be rewritten at some point. Along the same lines, it would be extremely advisable to isolate the functionality in a library to avoid the need to be rewritten everywhere it is used.

     

    Without such caveats, such suggestions can cause untold future pain.