custom list via ECL?

EDIT: of course now I read the Employee tag, and realize this might be overexplained.  But, in general its been working almost completely as expected for me.

We've been using ECL web servics and custom lists with great success (in a .NET platform, so C# and SQL Server) on 9.2.0.  I'm guessing the basic function remains the same when using the library directly.

The code around our calls has gotten rather abstracted, so I don't have any readily available sample code, but i can describe the general principals for each parameter, and some quirks we've run in to.

For starters, all our custom lists are based on query-backed BOs, no tables or other types.  This allows filtering to work as SQL.

When you bind the BO to the list, you only have to specify 1 column if you don't care about the UI.  All columns in the BO are returned through ECL regardless of how many you bind in the UI grid.  This is nice because then I don't have to reset 50 columns when I update the query BO.

It also helps to keep in mind that custom lists are run by Metastorm wrapping the BO query in a "select *" then appending your filters and sorting.  Using a simple query of all users in the eAlert table, if you filtered by eUserName and sorted them by time, the following query gets your results.  I'll set up this query in the resulting examples:

select * from
(select eUserName, eEventTime from eAlert)
where eUserName = "Nick"
order by eEventTime ASC

Parameters:

Session and listName are pretty self explanatory.  Note that you get an engine error if the session user does not have access to the list itself.

The sort direction is a list of KeyValuePairs (in C#) where the key is the column name, and the value is ASC or DESC.  These translate directly to SQL in the resulting query.  So for the above query, you'd need to pass the following value:
new KeyValuePair<string,string>("eEventTime", "ASC")

The filter parameter is pretty robust.  You can create basically any SQL operator, as well as groups.  The simple filter for the eUserName above is:

var userFilter = new ListFilter();

userFilter.FilterType = BusinessObjectFilterType.EqualTo;

userFilter.ColumnName = "eUserName";

userFilter.Args = new object[] { "Nick" };

You can also group filters using hte FilterType AndGroup and OrGroup.  In that ase, the Args parameter becomes an object array containing other ListFilters.  These end up generating actual SQL, and they work pretty much as you'd expect.  Explore the BusinessObjectFilterType enumeration.  It's got a lot of options.

The page number works as you'd expect.  It's 1 based, not 0 based (so its not an offset), and iirc passing 0 causes an error.  If you specify page 2 of a 100 item record set, with a page size of 20 (see below for a gotcha), you'd get items 21-40 in the results.

The page size parameter is actually ignored.  Page Size is determined solely by the Data Access setting on the custom list itself.  Bummer.  I usually just pass in the page size that I set in Metastorm as a reminder, but it does nothing.  This is described in the ECL documentation, however, so can't say we weren't informed.

 
Return values

The ListResult object returned contains a lot of interesting data points, but the big one is the Data value.  That's going to be XML that contains your return values.  If you inspect the return object, you'll notice that the XSD schema is actually embedded, so feel free to extract that and use it to create an object to serialize into.  It's what we do, and it works great.

You get a RecordCount to allow for paging, the current page, the page size from the BO, and apparently the where clause and the order by statement (I've not explored those parameters).

Ah, that makes sense.

We haven't had to deal with that kind of thing. We're running a weird setup where the engine is "headless": we don't use the web UI. I suspect GetListEx() just goes straight off the DB query, and that's how we use it: ECL web service access to database queries with filter options.  We extend the ToDo list with our app specific data, and display in a more "native" UI in our application (along with stages, form data, etc.)

The only thing I can think of is sort of a "reflective' custom list for other custom lists which returns the eGridLayout column in the eCustomList table, which gives you some layout information. You'd still have to figure out how to render the folder links, but at least it could tell if it was MEANT to be a folder.

I personally haven't played with that column at all, so I have no idea how the data is presented or what's included or anything of that nature. And most unfortunately, it doesn't contain any link to its backing data field, so you can't tell which value in the actual list maps to which column, so you'd have to rely on some sort of caption mapping

I suppose the secrets are locked in compiled code.

Hi Ari

Unfortunately this information is not available through ECL.WS.

As far as I know the web client uses ECL.Internal which does provide all the additional data that you are looking for. The problem is that use of ECL.Internal is not supported in custom clients.

Cheers

iain