Announcement

Collapse
No announcement yet.
X
Collapse
  • Page of 1
  • Filter
  • Time
Clear All
new posts
Previous template Next
    #1

    transformRequest/processResponse issue in latest nightly

    Hello,

    I have some code which worked fine under a previous nightly build of 8.0 (from 12-Feb). I downloaded the latest nightly (13-May) and it no longer works.

    I'm using a clientCustom approach and implementing the transformRequest/processResponse strategy for handling datasource requests.

    On the previous nightly build doing the following resulted in an alert dialog:
    Code:
    localDS.fetchData(null, function (dsResponse, data) {alert('callback ok');} );
    In the latest nightly nothing happens (no alert dialog, no javascript error and nothing in the ISC Console).

    I put Datasource into debug mode in the Console and can see the outbound request and I've used the IE debugger to step through the call to verify that transformRequest is invoked and that I ultimately call processResponse.

    I'd appreciate some pointers on where to look next? I think a support agreement is in place so I could put together a proper test-case and submit it next week if need be. For now I've reverted back to the previous nightly that I was using but I'd like to get up-to-date to benefit from your dataPath improvements.
    Tags: None
    #2
    We'd very much appreciate a test case for this. It doesn't seem likely there's a general regression in clientCustom DataSource since GWTRPCDataSource depends on it and a number of people are using that, with no reported problems. But whatever is causing this specific problem we'd like to fix it regardless.

    Comment

      #3
      Thanks for the speedy response, I haven't got the details of how to submit support tickets yet but will hope to get it to you next week (unfortunately I can't post it on a public forum)

      Comment

        #4
        What we're looking for is a minimal, standalone test case that clearly demonstrates a framework bug as opposed to an application-specific error. It need not and should not contain any organization-specific data or property names and would be expected to be probably 30 lines or less in a single file in this case. So it shouldn't need confidential treatment.

        Comment

          #5
          Hi,

          I've put together a test case as requested. It was quite a task to rip out as much of the cruft as possible. The code below works against a February nightly but doesn't do anything in the latest nightly (tested against 2011-05-17 LGPL).

          In writing this test case I figured out that it was the autoCacheAllData: true in WLEService that causes the problem - if I remove that property then it works.

          So my question is, is what I'm doing wrong? I have local page variable where I set all my data and I return it on the first fetch() request, or at least that's the idea.

          Code:
          <HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=IE8">
<TITLE>Test Case</TITLE>
<LINK REL="stylesheet" TYPE="text/css" HREF="">
<SCRIPT type="text/javascript">var isomorphicDir="/teamworks/script/custom/isomorphic/";</SCRIPT>
<SCRIPT type="text/javascript" src="script/custom/isomorphic/system/modules/ISC_Core.js"></SCRIPT>
<SCRIPT type="text/javascript" src="script/custom/isomorphic/system/modules/ISC_Foundation.js"></SCRIPT>
<SCRIPT type="text/javascript" src="script/custom/isomorphic/system/modules/ISC_Containers.js"></SCRIPT>
<SCRIPT type="text/javascript" src="script/custom/isomorphic/system/modules/ISC_Grids.js"></SCRIPT>
<SCRIPT type="text/javascript" src="script/custom/isomorphic/system/modules/ISC_Forms.js"></SCRIPT>
<SCRIPT type="text/javascript" src="script/custom/isomorphic/system/modules/ISC_DataBinding.js"></SCRIPT><SCRIPT type="text/javascript" src="/teamworks/script/custom/isomorphic/skins/Enterprise/load_skin.js"></SCRIPT>
</HEAD>
<BODY>
<script language="JavaScript">
				isc.defineClass("ISC_WLE").addClassProperties({
					 localData: {}
				});

				isc.defineClass("WLEDataSource", "DataSource").addProperties({
					clientOnly: true
				   ,init: function(args) {
						this.ID = args.name;
						this.Super("init", args);
					}
				});

				isc.defineClass("WLEService", "DataSource").addProperties({
				    autoCacheAllData: true
				   ,clientOnly: false
				   ,dataFormat: "custom"
				   ,operationBindings: [
						{operationType:"fetch", dataProtocol: 'clientCustom'}
				   ]
				   ,init: function(args) {
						this.ID = "WLEService_"+args.name;
						this.Super("init", args);
					}
				   ,transformRequest: function(dsRequest) {
						if (dsRequest.operationType == "fetch") {
							var dsResponse = {
								clientContext: dsRequest.clientContext
								,data: new Array(ISC_WLE.localData)
								,totalRows: 1, startRow: 0, endRow: 1 ,status: 0
							};
							this.processResponse( dsRequest.requestId, dsResponse );
							return;
						}
					}
				});
                Page.setEvent("load", function() {
                    ISC_WLE.localData = {"paymentStatuses":{"value":"Paid","name":"Paid"},"invoice":{"currency":"GBP","approved":false,"paymentStatus":"Unpaid","customerName":"SomeCo Intl.","lineItems":[{"dateArrivedAtWarehouse":new Date(1305654896553),"inStock":false,"dateShipped":new Date(1305654896553),"amount":93911.12,"taxRate":"19","quantity":1,"sku":"AKO-191"},{"dateArrivedAtWarehouse":new Date(1305654896553),"inStock":false,"dateShipped":new Date(1305654896553),"amount":1592.91,"taxRate":"19","quantity":5,"sku":"ZJQ-139"}],"date":new Date(1305654896551)}};
					WLEDataSource.create({"fields":[{"multiple":false,"type":"text","name":"name"},{"multiple":false,"type":"text","name":"value"}],"name":"NameValuePair"});
					WLEDataSource.create({"fields":[{"multiple":false,"type":"text","name":"sku"},{"multiple":false,"type":"integer","name":"quantity"},{"multiple":false,"type":"enum","name":"taxRate"},{"multiple":false,"type":"boolean","name":"inStock"},{"multiple":false,"type":"float","name":"amount"},{"multiple":false,"type":"date","name":"dateArrivedAtWarehouse"},{"multiple":false,"type":"date","name":"dateShipped"}],"name":"LineItem"});
					WLEDataSource.create({"fields":[{"multiple":false,"type":"text","name":"customerName"},{"multiple":false,"type":"date","name":"date"},{"multiple":false,"type":"text","name":"paymentStatus"},{"multiple":false,"type":"enum","name":"currency"},{"multiple":false,"type":"boolean","name":"approved"},{"multiple":true,"isComplex":true,"type":"LineItem","name":"lineItems"}],"name":"Invoice"});
					
					WLEService.create({"fields":[{"multiple":false,"isComplex":true,"type":"Invoice","name":"invoice"},{"multiple":false,"isComplex":true,"type":"NameValuePair","name":"paymentStatuses"},{"multiple":false,"type":"text","name":"tmp"},{"type":"text","name":"zTaskId","primaryKey":true}],"name":"Invoice"});

					ISC_WLE.localData.zTaskId = "p1";
					var serviceDS = DataSource.get("WLEService_Invoice");
					serviceDS.fetchData(null, function (dsResponse, data) {alert('callback ok'); isc.logEchoAll(data); } );
                });
             </script>
</BODY>
</HTML>

          Comment

            #6
            Thanks for taking the trouble to put this together. It identified a subtle problem that no amount of general description could ever really have elucidated. This has now been fixed and the fix will be present in the next nightly build.

            Comment

              #7
              Hi Isomorphic,

              You're welcome, thanks for the rapid fix. I know you're on the hunt for 8.1 bugs so I have another minor one for you.

              If I have a DynamicForm with a dataPath and a dataSource specified. I then add a header item in the form, only specifying defaultValue and type parameters (like in the documentation example). I get '[object Object]' output. I have to add dataPath: "/" on the header item in order for it to work correctly.

              Thanks!

              Comment

                #8
                It would be great to see a test case for that one too, otherwise, sorry but it's unlikely we'll be able to address it given all the other verified reports we're working on.

                Comment

                Previous template Next
                Working...
                X