DocumentsRequest.Download uses old url.

[GoogleCodeExporter]

As found by Fabrizio, the DocumentsRequest.Download method (The overload with 
the four parameters) constructs the export url using the document's resourceID, 
instead of docID.  
Can we update the method to get the export url from the content link like how 
it's done in the other overload:

string url = document.DocumentEntry.Content.Src.ToString();

Original issue reported on code.google.com by edwin.la...@gmail.com on 28 Jul 2010 at 8:19

• Merged into: #509

[GoogleCodeExporter]

please refer to
http://www.google.com/support/forum/p/apps-apis/thread?tid=7d0d55d17e93bfa0&hl=e
n

Original comment by mriquel...@gmail.com on 2 Oct 2010 at 6:18

[GoogleCodeExporter]

Original comment by ccherub...@google.com on 12 Dec 2010 at 1:16

[GoogleCodeExporter]

Correct form here would be to use the content link in the entry.

Original comment by vicfry...@google.com on 17 Dec 2010 at 8:57

[GoogleCodeExporter]

That overload with 4 parameters also accepts a baseDomain parameter. 
Should we take the content link and replace the base domain? 

You also mentioned using the resourceKey (i.e. resourceId without type:). 
What if we just replace ResourceId with a new property called ResourceKey built 
by getting what follows the ':' character in ResourceId?
To clarify, I would replace:

queryUri = baseDomain + "feeds/download/spreadsheets/Export?key=" + 
document.ResourceId + "&exportFormat="; 

with:

queryUri = baseDomain + "feeds/download/spreadsheets/Export?key=" + 
document.ResourceKey + "&exportFormat="; 

where 

ResourceKey = ResourceId.Substring(ResourceId.IndexOf(':'));

Will it work?

Original comment by ccherub...@google.com on 18 Dec 2010 at 2:12

[GoogleCodeExporter]

I don't see a reason to leave the base domain  in there.  Is there an advantage 
to being able to specify it that I'm not seeing?  It doesn't see proper to 
construct the queryUri from its parts.  It may work for documents and 
spreadsheets, but it's not possible for pdfs and files.  Plus, the document 
object is being passed, which should always have the content link.  

Original comment by ed...@edwinlandy.com on 18 Dec 2010 at 3:57

[GoogleCodeExporter]

My only concern is that it is a public method and by changing it we may break 
someone else's code.
Maybe Vic knows why you may want to specify the base domain.

Original comment by ccherub...@google.com on 18 Dec 2010 at 4:16

[GoogleCodeExporter]

Would it be okay to leave it as it is and mark it depreciated? We can refer 
users to the new overload with the new signature.

Original comment by ed...@edwinlandy.com on 18 Dec 2010 at 5:35

[GoogleCodeExporter]

@Claudio:  All of that base domain jazz should be tossed.  There is 
functionally no reason to manually construct these links in any way except to 
save a round-trip to the server in a bandwidth limited environment.

Despite that, if we do expose individual export methods here (e.g. one per 
doc-type,) the resource key mechanism is probably the way to go.  This is 
something I've discussed elsewhere, and have discussed with some other 
engineers on the Documents List API team.  We're considering returning both a 
resource key AND a resource ID.  The resource ID would be something like 
"spreadsheet:blah", and the resource key would be "blah".  Also, we're 
considering just killing the "spreadsheet:" part altogether, as it's pretty 
superfluous.

Assuming we don't do any of those things, the best solution is to remove the 
export method from the service class, and throw it on the data model, or 
mandate that the service class method take a data model parameter.  This would 
force entries to be used for exporting, and all entries will have a valid 
<content src=.../>.  I think we should do this and also incorporate Edwin's 
idea of marking the previous mechanisms deprecated.

Original comment by vicfry...@google.com on 20 Dec 2010 at 1:45

[GoogleCodeExporter]

Esto en que termino? yo aún tengo problemas para descargar una hoja de 
calculo, desde la  propia aplicación de ejemplo DocListExoprter, aún cuando 
me he descargado la ultima versión del GData SDK. que otra solución hay, como 
puedo resolver el inconveniente?

Error: 
Execution of request failed: 
http://spreadsheets.google.com/feeds/download/spreadsheets/Export?key=spreadshee
t:0Atd8RIy6W-_MdDlld2lrZm9TMzdBUlgzZWY0ZVo4Tmc&exportFormat=xls

Gracias!!!

Original comment by dardi...@gmail.com on 17 Feb 2011 at 10:33

[GoogleCodeExporter]

I Can't download(export) any doc by Use "DocListExporter.exe" (google samples 
code) until I modify the method 
"public Stream Download(Document document, Document.DownloadType type, string 
baseDomain, int sheetNumber)" of Class DocumentsRequest in "docrequest.cs" 
(...\clients\cs\src\documents3) and rebuild "Google.GData.Documents.dll"

In the method, I constructed the query uri by the sub string of 
"document.ResourceId"

VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
String subfid = document.ResourceId;
int isb = subfid.IndexOf(':');
if (isb>-1)
{
    subfid = subfid.Substring(isb + 1, subfid.Length - isb - 1);
}         
queryUri = baseDomain + "feeds/download/documents/Export?docID=" + subfid 
/*document.ResourceId*/ + "&exportFormat=" + type.ToString(); 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Also refer to  Issue 2154, may be it's a same problem.

By the way, if I use original Google.GData.Documents.dll of Google for 
exporting a doc, I get 404 error in 
method "public virtual void Execute()" of Class DocumentsRequest,

public virtual void Execute()
{
      try
            {
                EnsureWebRequest();
                // if we ever handed out a stream, we want to close it before doing the real excecution
                if (this.requestStream != null)
                {
                    this.requestStream.Close(); 
                }
                Tracing.TraceCall("calling the real execution over the webresponse");
                LogRequest(this.webRequest);
                this.webResponse = this.webRequest.GetResponse(); 
            } catch (WebException e) -----> 【e : 404 not found】
            {
                Tracing.TraceCall("GDataRequest::Execute failed: " + this.targetUri.ToString()); 
                GDataRequestException gde = new GDataRequestException("Execution of request failed: " + this.targetUri.ToString(), e);
                throw gde;
            }
    ...............
}

Is that a bug ? When can google fix it?

Original comment by coffi...@gmail.com on 10 Apr 2011 at 2:44

[GoogleCodeExporter]

@coffi....   as a workaround you can use 
     public Stream Download(Document document, string exportFormat)
It works fine with all type of docs.

Original comment by fht...@gmail.com on 10 Apr 2011 at 6:58

[GoogleCodeExporter]

@fht...

You are right， It works

Original comment by coffi...@gmail.com on 13 Apr 2011 at 6:51

[GoogleCodeExporter]

Original comment by ccherub...@google.com on 10 Jun 2011 at 9:34

• Changed state: Duplicate