Changes between Version 4 and Version 5 of DXInterface

11/07/06 11:05:06 (14 years ago)



  • DXInterface

    v4 v5  
    1818Given its fluid nature that is all we'll say about the DX WSDL for now. More pertinent to NDG is what you can send to the DX client as HTTP keyword-value pairs. 
    20 '''2. The DX CGI Arguments''' 
     20'''2. The DX User Interface CGI Arguments''' 
     22Within NDG2 it is most likely that users and applications will talk to the DX User Interface (DXUI). Hence they will need to know what arguments can be sent via HTTP POST or GET when some pre-selection has been made that is then pushed to the DX. The information below is still draft so comments are welcome. 
     24Recently I have modified the DX server to just express the axes of any variable/feature as "axis_<datasetGroup_n>.<dataset_n>.<variable_n>.<axis_n>". This makes it much more flexible for different types of feature/variable. However, from the client end it is slightly less accessible so the DXUI needs more intelligence.  
     26So, the DXUI is going to run at: 
     30You can pass the arguments: 
     34variable_<n>=<variable_ID>    # you can call this "feature_<n>" if you want 
     37Then I reckon I'll have to get it parse spatiotemporal stuff based on: 
     49Also, you can specify format with: 
     55That is all pretty much off the top of my head and I'll have to add a bit of code in the client to do it. However, should work. 
     57An example would be: 
     63In this way you could pass multiple variables/features. Inside the DX, it labels them systematically as: 
     83However, you probably don't want to get into that from an external viewpoint. You just want to follow the basic strategy in the above URL. 
     85NOTE: it might be bad practice to stick square (or any) brackets in the URL. If so, we can get around it by using (as the DXUI already does to get HTML form data across) <axis_id>_<n>_low and <axis_id>_<n>_high as the names.