JS Exception encountered on dynamic model initialize when no declarative models defined on page

This is based on the finding by Tanzir at http://community.skuid.com/skuid/topics/dynamic-model-createrowifnonefound-prevents-load?topic-repl…

When a page that does not contain any declarative models loads, the model service adapters are not being loaded. This results in any dynamic models failing to initialize because the following line of code returns undefined because ‘c’ is empty:

b.getService = function(a) {       
    return c[a || f]

In inspecting the resources loaded by the page, when the page does not contain a model, the file
skuid__SalesforceAdapterJS is not loaded (no script tag for it).

Currently, I don’t think the docs even mention the ability to create dynamic models using other adapters however this problem is bigger than just loading the salesforce adapter as the required adapter that the dynamic model needs would need to be loaded either on page load (not ideal) or on demand possibly during model.initialize() by inspecting the adapterName and checking to see if the adapter has been loaded yet.

Steps to reproduce:

  1. Create page from XML below (this is just a stock blank page)
  2. Preview page

Expected Result
Message “Successfully loaded!!” is output to console window

Actual Result
Javascript exception encountered -
"skuid__SkuidJS:formatted:11046 Uncaught TypeError: Cannot read property ‘getAdapter’ of undefined "

Sample Page XML

<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" showheader="true">    <models/>
            <jsitem location="inline" name="newInlineJS" cachelocation="false" url="">(function($S, $){
                    var accountModel = new skuid&#46;model&#46;Model();
                    accountModel&#46;objectName = 'Account';
                    accountModel&#46;id = 'Account';
                    accountModel&#46;recordsLimit = 1;
                    accountModel&#46;fields = [
                         { id: 'Id' }
                        , { id: 'Name' }
                        &#46;done(function() {
                            console&#46;log('Successfully loaded!!');
                        &#46;fail(function() {
                           console&#46;log('failed to load!!') ;
                })(skuid, skuid&#46;$);</jsitem>
            <styleitem type="background" bgtype="none"/>

Skuid Team - Any insight on this?

This issue was originally posted nearly 2.5 months ago but has yet to be acknowledged or commented on by the Skuid team.  Just tested with 9.3.1 and while the code path is different, this issue still exists.

In 9.3.1, the faulting code path is a result of a.getDataSource() within S(c, f, g) returning undefined because the adapter is not loaded.  Essentially, the same issue as Banzai had just manifesting in a slightly different way.

Can someone from the Skuid team please acknowledge/confirm/reject/comment on this?

Thank you!

Can someone from the Skuid team please acknowledge/confirm/reject/comment on this?

Skuid Team - Any insight on this?

Hi Barry. Thank you for taking the time to investigate and bring this up. I see the behavior you’re describing, using your example XML, and I will bring it to the attention of our dev team. It looks like if you add a non UI-only model with a default row (just as a placeholder), that will load up the necessary back-end elements. In my case, I used Salesforce as the Data Source Type. That could be a pretty lightweight method to use in such a scenario. What do you think?

Barry, our dev teams have this issue on their radar, and will be addressing it with a future release. 

Hi Mark -

Thanks for looking in to this and confirming the issue.

You are correct, using a non-UI only model with Salesforce as the data source type does workaround the issue.  However, as I mentioned here, the least impactful workaround is just to have a model with “load data” = false and “create row” = false.  This brings in the adapter JS file but limits the performance and memory footprint impact (creating a row takes an unncessary perf hit and memory usage and isn’t needed).

One thing to keep in mind as this issue is being resolved is that the problem exists beyond just Salesforce models - any dynamic model using any data source type would ultimately encounter this issue.  The only viable workaround currently is to ensure that you have a declaritive model with that data source type defined on your page.