Common practice for data sources

[wallytax]

What is the "preferred" way of creating data sources (I'm using SmartClient 10) in general? So far I'm creating a BaseDataSource class, extending the default RestDataSource class and for each entity I subclass this class to set the field configuration and data URL. After that I create a global instance via an ID. In a lot of examples I see only the usage of the global instance (so for all places in an application using a customers data source, it seems like the same instance is used. I guess this is done to have automatic data binding, but I wonder if there's downsides to this.

So this is what I have:

    // create a base class that sets up properties to talk with a RubyOnRails back-end
    isc.defineClass('BaseRestDataSource', isc.RestDataSource).addProperties({
        dataFormat: 'json',
        operationBindings: [
            { operationType: 'fetch', requestProperties: { httpMethod: 'GET' } },
            { operationType: 'add', requestProperties: { httpMethod: 'POST' } },
            { operationType: 'update', requestProperties: { httpMethod: 'POST', params: { '_method': 'PUT' } } },
            { operationType: 'remove', requestProperties: { httpMethod: 'POST', params: { '_method': 'DELETE' } } }
        ],
        sendMetaData: false,
        transformRequest: function (request) {
            if (request.operationType === 'fetch') {
                // check if paging is enabled
                if ((request.startRow !== undefined) && (request.endRow !== undefined)) {
                    request.params = isc.addProperties({}, request.params, {
                        offset: request.startRow,
                        limit: request.endRow - request.startRow
                    });
                }
            } else {
                request.data = isc.addProperties({}, request.data, {
                    authenticity_token: METADATA.authenticity_token
                });
            }
            return this.Super('transformRequest', arguments);
        }
    });

    // create a entity specific subclass
    isc.defineClass('CustomersDataSource', isc.BaseRestDataSource).addProperties({
        dataURL: '/api/customers',
        fields: [
            ...
        ]
    });

    // create a global instance
    isc.CustomersDataSource.create({
        ID: 'customers'
    });

So, I might remove the creation of the entity specific subclass and create instances instead of them (thus combining the last two steps). I don't really like the idea of working with the IDs to create global instances, but it does help in creating simpler code.

[Isomorphic]

There is no reason to have multiple separate instances of the same DataSource. A DataSource instance represents the definition of an entity and is roughly equivalent to the way a Java *Class* (*not* instance) is used in Hibernate and other ORM systems.

There are already multiple ResultSets to handle different distinct caches that result from load on demand combined with different criteria and sort directions.

Except for handling legacy server-side behaviors, there is not really a reason to customize the default RestDataSource at all. But if you had a valid reason to customize RestDataSource, yes you would create a subclass, and create one instance of that subclass per entity type in your application.

[wallytax]

I will definitely remove the subclass then and use direct instantiations. The reason I subclass the default RestDataSource is because I want to set some properties differently. I will see if I can remove that as well. Not sure if the defaults (especially the operationBindings) will work with Rails.

[Isomorphic]

I will definitely remove the subclass then and use direct instantiations.

That's not what we said. Again:

Except for handling legacy server-side behaviors, there is not really a reason to customize the default RestDataSource at all. But if you had a valid reason to customize RestDataSource, yes you would create a subclass, and create one instance of that subclass per entity type in your application.