Nonsensical error with rawData property on Store

[TerryB]

I've seen some strange stuff but this one takes the cake. This app works fine in Val 5.2. I only have one version of source code for app for both 5.2 and 6, the app runs directly on source code (no build).

This is that technique when you return store data from server and build in properties. The most common is the "totalProperty" where you send total records to paging toolbar.

In this case, I return some totals to display at top of grid. So store has the keepRawData parameter. I use the onload event to fetch those properties and display in fields on toolbar of grid. Works fine in 5.2, I get a null object error is Val 6 (extjs 7). It fails on statement below, saying totalCULbs can't be retrieved from null.

What makes no sense is that I use this technique in many apps and they all work, just this one does not. This app does have far more properties than other but I checked in debugger, the reply from server is fine. I don't get this one at all.

Line 66 of maingrid is below, along with definition in Store.

Uncaught TypeError: Cannot read property 'totalCULbs' of null
onLoad @ :7060/dev/FirmOrderInq/view/MainGrid.js?_dc=1600188842827:66
fire @ :7060/ext/build/ext-all.js:20
doFireEvent @ :7060/ext/build/ext-all.js:20
b.doFireEvent @ :7060/ext/build/ext-all.js:20
fireEventArgs @ :7060/ext/build/ext-all.js:20
fireEvent @ :7060/ext/build/ext-all.js:20
onProxyLoad @ :7060/ext/build/ext-all.js:20
triggerCallbacks @ :7060/ext/build/ext-all.js:20
setCompleted @ :7060/ext/build/ext-all.js:20
setSuccessful @ :7060/ext/build/ext-all.js:20
process @ :7060/ext/build/ext-all.js:20
processResponse @ :7060/ext/build/ext-all.js:20
(anonymous) @ :7060/ext/build/ext-all.js:20
callback @ :7060/ext/build/ext-all.js:20
onComplete @ :7060/ext/build/ext-all.js:20
onStateChange @ :7060/ext/build/ext-all.js:20
(anonymous) @ :7060/ext/build/ext-all.js:20
elevate @ :7060/ext/build/ext-all.js:20
(anonymous) @ :7060/ext/build/ext-all.js:20
a.<computed> @ :7060/resources/valence.js:1
D @ :7060/resources/valence.js:1
b @ :7060/resources/valence.js:1
b @ :7060/resources/valence.js:1
p @ :7060/resources/valence.js:1
h.onreadystatechange @ :7060/resources/valence.js:1

var amt = st.getProxy().getReader().rawData.totalCULbs.toFixed(0);


reader : {
type : 'json',
root : 'FIRMOPNDS',
keepRawData: true,
totalProperty: 'totalCount',
totalCULbs: 'totalCULbs',
totalCUAmt: 'totalCUAmt',
totalZNAmt: 'totalZNAmt',
totalZNLbs: 'totalZNLbs',
totalCUDiff: 'totalCUDiff',
prcDate: 'prcDate',
stdCUPrc: 'stdCUPrc',
stdZNPrc: 'stdZNPrc',
totalZNDiff: 'totalZNDiff' },

[sean.lanktree]

Hi Terry -

We highly recommend you do not load Ext into your applications from the Valence folder. Your apps should be self sufficient...meaning it would pull the version of Ext that you want to use and not whatever is used for that version of Valence. Otherwise, each time you upgrade Valence you are dependent on what version we used and this will be problematic for your applications. Your applications should not need to be modified just because you are running them in a different version of the Portal.

I would recommend the following:

• Create a new folder on your IFS to hold the Ext library that you want to use. Be sure that this is outside of any Valence folder structure
• Point your applications to pull Ext from this new path.

[TerryB]

Hi Sean,

I get I could AVOID any changes to extjs itself by using that technique, such as avoid bugs that may have been introduced or any use of extjs which has deprecated. But you and I both know it's more complicated than that because of how CSS interacts with these damn ever changing browsers. The episode with the border radius in Chrome browser not long ago proved that, it had nothing to do with Extjs version.

I suspect I'm not alone in using your new releases to "vet" the release of Extjs you choose to include in your release. Meaning, if good enough for you, then good enough for me. As a best practice, especially old IBM mainframe/i5 guys like me, you ALWAYS want the latest and greatest programming languages. Could you imagine still using RPG as it existed in 1985? You trust that new version are backwards compatible to previous version, unless they specifically tell you it is not. I would expect you guys would warn us if new extjs version had some major break with the past. I'm a one person shop here, to think I have time to evaluate Extjs versions on my own is not feasible. I trust you guys trust the release is stable, which is good enough for me.

All this said, I am going to have to do as you suggest because I've recently upgraded directly with Sencha to the Enterprise license so I can use their Calendar and Pivot Grid in future apps. I just haven't had time to get there yet,

Richard was going to give me some advice on exactly how I implement such a thing within your framework. It isn't trivial, I now have 374 apps (and counting) with index.html files using strictly your loader to access extjs. I didn't have to change any of them to implement Val 6. My goal would be to work with your loader code so I'm not changing all these with every new release of Valence.

Anyway, back to this issue. Additional testing this morning has found that this is also a CSS/browser problem, nothing to do with directly with Extjs 7. This app only breaks in the Chrome and Edge (pre Chromium) browsers, works fine in IE11. And I've discovered nothing to do with rawData properties, the grid itself does not bind and render after I comment out the code referencing the rawData properties. And not same way as the border radius problem, it actually shows the value of the emptyText value, even though rows of data were returned correctly. The grid renders, just empty.

[sean.lanktree]

Hi Terry -

I understand what you are saying however still strongly suggest you work with your own Ext codebase. Unlike RPG, Javascript frameworks are not always necessarily backward compatible....because there are many more moving parts.

When we upgrade the Javascript framework for Valence, we usually undergo many changes in our code to accommodate it. It doesn't usually just work out of the box with our old code.

If you are using a single file to load all of your Ext resources then it should be really easy to implement. You would only need to change the one file and likely put in a new apache directive to map it to your Ext codebase.

Sean

[TerryB]

Thanks Sean. I'll reach out to you guys when I get to the point of needing to implement the Extjs with the enterprise stuff. I'm tied up prepping for major shopfloor releases of apps which will replace the green screen apps they currently use. Once I clear this and can start creating apps using Calendar and Pivot Grid, I'll ask for detailed advice on the best way to implement.

One suggestion though. I'm not sure how common a customer I am compared to your others but everything I do with extjs I learned from you guys. Your sample MVC My Tickets example is the foundation of everything I've since learned. If you find changes to Extjs where you need to change programming techniques, I would love to see those in the release notes. I could very well be using same technique, that would really help if it is feasible.

Let me know what you think about this bug. There is no hurry here but I suspect we'll need to do another web session eventually so you can look at what is going on, like you did the for border radius problem. I'm not good enough to solve this on my own, :o

[TerryB]

Sean, thanks again for taking time to remote to me and work through this. I was not understanding what you were getting at with your initial reply. Sorry for the back and forth. You guys are the best.