Edit | Copy should always grab REST ID

[Tungurahua]

I could be wrong here, but I think the right behaviour for the Edit | Copy Menu should always be to move the current REST-ID to the clipboard. Right now it returns the ID if it has been selected before.

[amattioc]

The copy action can be performed in any text window of the helper. It can be helpful if you want to copy&paste an error message...

Maybe I can add a specific action for getting the query...

[Tungurahua]

Point taken!

However, as you mentioned a specific action: would it be possible to create an action that formats the REST-ID into an getSDMX() call and makes it available on the clipboard? Obviously this is a request from an R user, but in my opinion, something similar would make sense for the other connectors as well.

I know that you are planning the helper to interact with the calling software. However, for the specific R-case I think that this would still mean some copying and pasting, e.g. I think the work-flow would be as follows:

# Assign the return value of the helper to a variable in the console
# This will return the REST-ID once the helper is closed
var <- sdmxHelp()

# To include the REST-ID into a script, I would do 
dput(var)
# copy the returned value to the script and tweak the REST-ID to conform to 
getSDMX("EUROSTAT","xxxxx....")

In my opinion, having an action in the helper that pre-formats the command would be more straightforward. Especially since the helper would have to be closed for every new REST-ID. From a GUI-perspective I think this could be implemented by another selection menu with the name "ReturnValue" with entries like

• asis returns the RESTID as displayed right now in the helper. Used to retrieve SDMX-XML from a browser, possibly prepend the SDMX-endpoint to make it a full-fledged URL.
• R returns the pre-formatted R command
• Matlab returns the pre-formatted Matlab command
• Excel raises a fatal error and shuts down all running applications ;-)
• ...

This could be taken further by allowing a series of REST-IDs to be written into a text-file for further processing. However, this idea is determined very much by a current work-assignment of mine.

[amattioc]

Hi, returning the call string is an idea, but wouldn't it be more useful to get the time series in output? It would be like an interactive getTimeseries this way. What do you think?

I also like the full URL idea. It could be useful in many contexts.

[Tungurahua]

The advantage of returning the preformatted command (e.g. getSDMX("EUROSTAT", "proj_13nanmig.A.TOTAL.T.") is that it would take fewer steps to include this into script to be re-used at a later time. Right now I retrieve proj_13nanmig/A.TOTAL.T. where I have to replace / with ., wrap the two parts into double-commas and copy this into the getSDMX command. Admittedly it's no issue to write a wrapper function to achieve this behaviour. So it's more a matter of convenience. However, running an interactive analysis from this return value will be a single keystroke, while producing the command from an interactive session seems to be more involved.

Apart from that, the suggested solution would be advantageous when you want to create a series of getSDMX() commands as you would not have to close the Java application (but maybe this is possible as well).

Personally I tend to give more value to reproducibility of work than to convenient interactive usage, but that's certainly a matter of taste.

Best regards Albrecht

[amattioc]

I perfectly understand your point and I agree.

My idea is the following: I'll add a selection box somewhere that lets the user choose what is displayed in the query box (e.g simple query, URL, R, MATLAB etc.). This way the helper can be iteratively used to build the right needed commands (that can then be copied to the script or wherever needed). And there will be no need to close the helper after every command.

What about that?

Best, Attilio

[Tungurahua]

This is exactly what I am looking for.

The only further addition I would suggest is to allow to redirect the the commands to a seperate file. The idea behind this is to compile all necessary REST-calls in a first step and use it for analysis then. Gui-wise this could be implemented as a check box (if selected pipe to file) and a file selector (defaulting to user home directory). If the box is checked this would create a *.csv file in e.g. the following format:

 provider; ID
 EUROSTAT; tsdsc310.W.PC_Y_LT60.
 EUROSTAT; rd_e_berdcostr2..CUR_LC.D_E.MIO_NAC.
 WB; WDI.A.EE_BOD_CHEM_ZS.

However, this last point is a requirement that would come in handy for a apecific assignment I am currently tasked with and I don't know if it would make sense as a general feature. In addition, I am already more than thankful that you provided the great number of additions to the package. So this is rather a "nice to have" than a requirement.

[amattioc]

You're welcome. Your feedback will be helpful for my internal users too.

[gplopez]

I agree, infact this is essentially quite the same feature that we have on another internal navigation tool, in which we let users to export the result of navigation/search to statements of a specified 4GL language (e.g. SAS, R, etc..)

[amattioc]

Hi, in 79879f05956571b3bcbbafa6cf37cd478fdc05b3 i introduced a new action (in the menu bar) that lets the user export the pre-formatted commands for R, MATLAB, SAS. I'll add the complete URL of the data query (for use in a browser) later.

Attilio

[amattioc]

In b5a877744cbbaf0198e7f351930122153af60f75 I also added the http URL to the list of commands. It can be used in a browser...

[amattioc]

I close this issue; feel free to reopen if you get problems or want ot add something.

Best

[Tungurahua]

Sweet!