Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    #16
    In firebug, I am getting further information:
    Code:
    Cannot find resource 'sc/IDACall' in the public path of module 'gov.ca.dot.tpot.Application'
    
    Cannot find resource 'sc/HttpProxy' in the public path of module 'gov.ca.dot.tpot.Application'
    [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: http://localhost:8888/gov.ca.dot.tpot.Application/sc/modules/ISC_Core.js?isc_version=7.0beta.js :: anonymous :: line 729"  data: no]
    http://localhost:8888/gov.ca.dot.tpot.Application/sc/modules/ISC_Core.js?isc_version=7.0beta.js
    Line 729

    Comment


      #17
      Please ignore all of this stuff about IDACall, HttpProxy, etc - these are all red herrings - the fundamental problem is that your attempt to load your WSDL is failing as reported by the Developer Console. All these other errors are coming from fallback strategies after that failure. Also ignore the loadWSDL functionality in the Developer Console for now.

      Looking at your attempt to call XMLTools.loadWSDL(): you are specifying a URL beginning with "http://..". Have you looked in the RPC tab in the Developer Console to see whether there is even a request to this address? If not, try specifying this URL as a relative URL. If you're not able to do so (maybe it's on a different port) then the real problem is that web application are not allowed to access machines other than the one where the page was loaded from, including just a different port number.

      Comment


        #18
        The wsdls with the URL's below load without issue from within developer console, and am able to send a fetch operation request, and receive a response on both the custom wsdl as SmartClientOperations.wsdl from within developer console. URL format works, port numbers match.

        Moved the loading of WSDL to application initialization, delaying construction of the listgrid until WSDL's are loaded using the WSDLLoadCallback.execute() callback. This resulted in different behaviour. With the custom data source, still getting a hiccup on the red herring...However, with WSDataSource homed in on SmartClientOperations now getting fetch invocations! Haven't arrived yet, now ListGrid keeps fetching data in an endless loop. But that's a new story. Suspect it may have something to do with the response format.

        Thanks for all the help.

        Comment


          #19
          Success

          Both DataSource implementations are working like a charm! As per your feedback, amounted to making datasource creation and service namespace setting conditional on successful loading of WSDL.
          Code:
          XMLTools.loadWSDL(
               	"http://localhost:8080/tpot-smartgwt-2008-01/services/TPOTSOAP?wsdl", 
                  new WSDLLoadCallback()
                  {
          		public void execute(WebService webService)
          		{
          		   dataTabSet.addProjectSummaryDataGridTab();						
          		}
          	});
          Thank you for your help. This is a pretty amazing framework you have going here!

          Comment


            #20
            Good to hear :) As you move on toward saving data be sure to look at useFlatFields, it greatly simplifies the process of putting together valid response data.

            Comment


              #21
              Thank you. Also discovered that WSDataSource made for a better starting point for backing a ListGrid than a straight DataSource which appears to drop the startRow / endRow request parameters.

              Comment


                #22
                On that, see transformRequest() - RestDataSource and WSDataSource are assuming a particular protocol. All other DataSources start with the assumption that the server won't understand metadata like startRow, endRow, sortBy, oldValues, etc, and that you will override transformRequest() to add these as needed.

                Comment


                  #23
                  It appears that with WSDataSource, no information is received server-side as to sort-fields / sort-directions in the DSRequest.data field where I was expecting them alongside search criteria. Is overriding transformRequest() what is needed here?

                  Comment


                    #24
                    Hmm, you're right, sortBy was missing - it's now been corrected.

                    To fix, override transformRequest() to add sortBy to the data as you said, then also modify the WSDL so it has an entry for sortBy in the request:

                    Code:
                                        <xsd:element    name="startRow"         type="xsd:long" minOccurs="0"/>
                                        <xsd:element    name="endRow"           type="xsd:long" minOccurs="0"/>
                                        <xsd:element    name="sortBy"           type="xsd:string" minOccurs="0"/>
                    Note by the way that server sorting is not actually required unless you are returning a partial result.

                    [Edited: sortBy should be type="xsd:string", was originally posted as "xsd:long"]
                    Last edited by Isomorphic; 8 Dec 2008, 22:14.

                    Comment


                      #25
                      Note type of sortBy should be xsd:string, not xsd:long as originally posted. We've corrected the previous post.

                      Comment


                        #26
                        When you say 'sortBy' was missing, where was it missing?

                        Do I understand this right?
                        By overriding transformRequest(DSRequest original), information not directly originating from ListGrid can be added to the request. If I need to add sortBy to transformRequest, because it is not being supplied by ListGrid, then I need to detect which column's sort direction was changed somehow and make this available to the overridden function, e.g. using a CellClickHandler?

                        Comment


                          #27
                          Does sortBy combine information about both the column being sorted and the sort direction?

                          Comment


                            #28
                            The ListGrid supplies sortBy and it appears in the DSRequest. However, transformRequest() on the WSDataSource in particular wasn't copying sortBy into the data that is serialized to XML. So, you just need an override that copies sortBy into the default return value of transformRequest().

                            Yes, sortBy contains both direction and fieldName.

                            Comment


                              #29
                              Got it...can see where it is missing now: WSDataSource.js.
                              Thank you.

                              Comment


                                #30
                                sortBy success

                                Got it to work overriding DataSource.transformRequest with this one using gwt/jsni, and adding the sortBy field to the WSDL per your directions:

                                Code:
                                	protected native Object transformRequest(DSRequest dsRequest) /*-{
                                        	var self = this.@com.smartgwt.client.core.BaseClass::getOrCreateJsObj()();
                                        	var rqjs = dsRequest.@com.smartgwt.client.data.DSRequest::getJsObj()();
                                        	var transdata = self.__transformRequest(rqjs);
                                        	if(rqjs.sortBy != null)
                                        	{
                                        		transdata.sortBy = rqjs.sortBy;
                                        	}
                                        	return transdata;
                                    	}-*/;

                                Comment

                                Working...
                                X