The browser client's Z39.50 code did not make any changes to underlying APIs used to fetch the list of Z39.50 targets and search attributes; I don't think there's any spillover going on here.
Rather, other than the item type being fixed at the top, the order of search attributes in the XUL interface is not currently defined, and can vary based on:
- subtle differences in how the XUL JavaScript engine iterates over JavaScript hashes
- the order in which attributes are returned by the open-ils.search.z3950.retrieve_services call, if the client's JavaScript engine is pulling out attributes in insertion order (and again, that API is not sorting
In srfsh, you mind try running the following repeatedly and see if you get any different results at time:
The browser client's Z39.50 code did not make any changes to underlying APIs used to fetch the list of Z39.50 targets and search attributes; I don't think there's any spillover going on here.
Rather, other than the item type being fixed at the top, the order of search attributes in the XUL interface is not currently defined, and can vary based on:
- subtle differences in how the XUL JavaScript engine iterates over JavaScript hashes search. z3950.retrieve_ services call, if the client's JavaScript engine is pulling out attributes in insertion order (and again, that API is not sorting
- the order in which attributes are returned by the open-ils.
In srfsh, you mind try running the following repeatedly and see if you get any different results at time:
request open-ils.search open-ils. search. z3950.retrieve_ services "$AUTHKEY"
In any event, the for the moment would be to provide an explicit ordering, e.g., alphabetical by label.