Generating an external content URL

[aspa]

I'm accessing documents stored in Alfresco 2.1 using Java based web service client in a similar fashion as in the Wiki examples (http://wiki.alfresco.com/wiki/Web_Service_Samples_for_Java, Query1.java).

A direct URL link should be presented to the user in the search results page.
What's the proper way to generate such a link so that it would allow the user to directly download the content from Alfresco?

[schambon]

You should be using the DownloadContentServlet described here :

http://wiki.alfresco.com/wiki/URL_Addressability

Since you're using the web services, use them to get an authentication ticket then use that in the URL.

-Sylvain.

[aspa]

I've experimented a bit with constructing URLs but I'm having problems constructing the path to a
a content item. I'm trying to construct URLs of the form

/alfresco/download/direct?path=/Company%20Home/My%20Home%20Space/myimage.jpg

as described in the Wiki article. I used the WS API to get the path to a content item. The path looks like this as reported by Alfresco 2.1:

/{http://www.alfresco.org/model/application/1.0}company_home/{http://www.alfresco.org/model/applicatio...

After removing the namespace prefixes it looks like this:

/company_home/guest_home/Alfresco-Tutorial.pdf

http://localhost:7080/alfresco/download/direct?path=/company_home/guest_home/Alfresco-Tutorial.pdf

When I try to use this URL I get the above error message.

path=/Company%20Home/Guest%20Home/Alfresco-Tutorial.pdf doesn't work either but
path=/Company%20Home/vieraan%20koti/Alfresco-Tutorial.pdf works.

Here the first two path components are different from the path received via the WS API query.
"Guest Home" seems to have to be localized here. The path needs to be localized even if the active user session is in english.

Is this a bug?

How would I construct the URL in this case when the client might not know which locale to use?

[schambon]

Can't you simply pass around a node reference, ie URLs of the form /alfresco/download/direct/workspace/SpacesStore/0000-0000-0000-0000/myfile.pdf (replace the string of zeros by the node's id)?

That would free you of all localization issues, plus the link would remain valid if the node gets moved around, etc.

-Sylvain.

[aspa]

I originally just picked a documented method for constructing URLs and expected that to work, I don't have any problems using another. If it just works.

So, speaking in terms of properties returned by the Java WS client API, is this the correct way to map properties to URL components?

/alfresco/download/<direct|attach>/<store-protocol>/<store-identifier>/<node-uuid>/<name>

[schambon]

Hi,

Re the problem with internationalization: basic repository layout is created when the repository first starts up according to the server's locale setting. That is to say the "guest home" component will be called "Guest Home" if you first started up on an English-locale server but something else if you first started up on a different-locale server (vieraan koti in your case). Once the objects have been created their name is fixed, no matter what the current user's language setting is.

The documented example uses cm:name-based paths, ie human-readable, internationalized paths by contrast to machine-readable, "technical" paths like app:company_home/app:guest_home. So you'll have to provide paths related to your server's locale.

That certainly works as documented, but gives you more work to do, which is why I suggest using the node's uuid (simpler is better in my book).

Re the mapping of properties to URL components: yes, that's it.

Regards,
-Sylvain.

[aspa]

There's two components in the path that differ from the WS API representation:
- company_home ==> Company Home
- guest_home ==> vieraan koti

The first one isn't localized while the second one is.

If the DownloadContentServlet uses a different path representation, with localized parts, why can't the WS API use the same form? Or the other way around?

It could be that the client developer might not know which locale the server is using, and the locale might even change during the service lifecycle, so IMHO it's not good to force the client developer take this into account.

Anyway, I'll test the other method described in the Wiki article.

Thanks for the help, Sylvain.