Get file path for document

[Marc Howard, geändert vor 9 Jahren.]

I have uploaded a css file that i want to be able to view in the browser. If i use the "GetURL" method it gives me the link to the document, but runs a GET method and downloads the file. How can i access the file directly with the absolute path?

[Ravi Kumar Gupta, geändert vor 9 Jahren.]

Marc,
Correct me if I am wrong,
If you uploaded your file in document library, what's happening above will happen. If you need to use that css file for other use like include in a webpage(html) then put that in a directory in webapps(in tomcat) and use like http://server-name:port/dir-name/abc.css

What is your use case anyways.. ?

[Andew Jardine, geändert vor 8 Jahren.]

Hey Marc,

Did you ever get what you were looking for? if you did can you share? I'm currently in the process if digging through the source to try to find out if and where I can control the names of the directories on the file system that are created.

To clarify: Does anyone know which class in the DL API is used to create the physical directories on the disk? I can see that there is a reference to building the path -- dlFolder.setTreePath(dlFolder.buildTreePath()); -- and what I am wondering is whether or not I can hook this service api to use folder names _I_ need rather than the ids created by Liferay.

[David H Nebinger, geändert vor 8 Jahren.]

Andrew, it depends upon your DL implementation. There's file store, advanced file store, DB store, D3 store (for AWS), etc.

You typically don't need to hit the filesystem directly as you can use the DL API to pull the doc contents regardless of the store mechanism being used.

[Andew Jardine, geändert vor 8 Jahren.]

Hey David,

Totally agree with you and that is how I was hoping to improve the current system being replaced. Let me expand on the details a bit.

There is currently a "Liferay application" that isn't really a Liferay application. I'm working with a couple of others to "migrate it" into a new application but this time I am trying to leverage as much of the portal as possible (afterall, my client holds EE licenses, might as well get the most you can out of them right?). In the old system, as part of the workflow, a file was generated and placed on the disk (a NAS to be precise). The path where the file was placed was pretty obtuse, a series of numbers and dashes to other numbers etc. Not exactly what you would call "user friendly".

In the new system I was hoping to leverage the DL and use semantic naming for the paths under which the files were stored. Something like --

/[application-name]/2015/august/[account name]/<files>

We were going to place the mount point for the document library such that it references the root location where the NAS is used. I did a quick POC to get some code to auto-detect and generate in its adsence the path for a new month, year, account etc. On the disk of course Liferay generates soemthing like

/companyid/groupid/..../version-number

and as I thought users would use the DL interface instead of the file system, I didn't think it would matter. Here's the rub.

Problem: At the end of the process the file that is generated must have a specific name (whcih is not an issue) and be in a specific location on the NAS because there are other system on the network that will, post SOAP service call, look for these files.

So what I need is, to control the folders and files names in the DL for users (done). But then when I am adding a DLFolder, I need to be able to specify the exact directory structure including names on the disk.

I haven't tried it yet, but I am wondering if the treePath paramter can be used for this purpose. If not, or there is a better way -- I am all ears -- err, eyes I guess in this case.

[David H Nebinger, geändert vor 8 Jahren.]

Files and folders have a name as well as an id, but the FS hooks typically use the IDs.

If you're doing a soap web service to get the files and/or list, doesn't that mean you can still leverage the DL? Liferay uses the /companyid/groupid stuff as a prefix, but under there you could put /appName/2015/august/account/... and then your code will just have to start from the root and get the folder (using name) for appName, then 2015, then august, then account and finally the file. All using the DL apis, just you wouldn't have any idea where they are on the filesystem.

Perhaps I'm missing something though...

[Andew Jardine, geändert vor 8 Jahren.]

Hey David,

It's probably less that you are missing something and more about my explanation being too obtuse. Let me outline the workflow is detail.

Pre-Conditions: Liferay DL is set to a mount point for /mnt/external/liferay

1. User logs into the application.
2. User initiates a new "Request"
3. User completes a workflow filling in the request details, and also includes one or more attachments.
4. User submits.
5. The files are added using the DL to a semantic path (visible in the control panel) of /requests/2015/august/Acme
6. The request details are packaged into a SOAP request and sent to an ESB.
7. Liferay application receives a successful result from ESB.
8. A secondary system (I beleive it is Siebel) picks up the new request and starts processing it.
9. As part of it's processing it looks at the payload and constructs a semi-hardcoded file system path ... eg. /RequestFiles/0999312-231421/984121421-1423-1
10. It then uses this path to check the NAS for the physical files -- directly, not through Liferay or Liferay's external API.

This Siebel system being altered to accept a location in the SOAP request or something is not in scope so we can't do it that way. We need the physical file path that Liferay stores the item at to match the one that Siebel "calculates" but we want to keep the "control panel version" as one that is more friendly for users.

So my question is -- I know I can create the folders and files with whatever "vanity name" I like, but can I also force the directory and physcial file names to be something different without breaking the entire API for things like search, versioning, permissions etc. This would allow me to create a better UX for the actual users of the system and also allow the external system to continue to function without change.

Does that clear things up a bit?

[David H Nebinger, geändert vor 8 Jahren.]

Hmm, I guess so.

So the FS hook is not going to use the semantic names for paths... I guess you might try something like a model listener on DLFileEntry guys and, after create, create a soft link from a semantic path to the actual file... I don't know if you're linux-based, but if you are you could exec "ln -s /path/to/real/file /semantic/path/with/filename" and that will work regardless if the file is actually there yet or not (I believe when the model listener gets invoked the actual file might not have been created yet).

Just a thought, would allow you to use the DL for your file store yet still expose it in a way that it would be visible on the NAS...

[Andew Jardine, geändert vor 8 Jahren.]

Hey David,

We are on Linux and that was one of the ideas we were throwing around -- mostly because the confidence level of everything working as it is supposed to with that level of "customization" was pretty low. I'll have a look at that and report back here what we end up doing. Thanks!

[Jack Bakker, geändert vor 8 Jahren.]

management of symbolic links on linux would have its own overhead, yikes

I am guessing Andrew has been digging deep into the Liferay code again and is looking to programmatically refer to parameterized custom file path syntax somehow

looking forward to report back Andrew

[David H Nebinger, geändert vor 8 Jahren.]

Totally agree about symbolic links, but trying to force Liferay's store hook to use named paths instead of the ids, well that in itself will be a pretty invasive solution.

The model listener should at least give you the appropriate entry points for symbolic link maintenance, though. You get create access, update access (for name change or folder change or ...) and delete access.

Not saying it's a pretty solution, but it is probably the least impactful.

[Andrew Jardine, geändert vor 8 Jahren.]

I am guessing Andrew has been digging deep into the Liferay code again

.. seriously. Someone should buy me a mining hard hat and a shovel.

[David H Nebinger, geändert vor 8 Jahren.]

rotfl... That's where I've been on LR7, mining nuggets of truth (as much as I can) from the milestones...

[Jack Bakker, geändert vor 8 Jahren.]

Andrew Jardine:

I am guessing Andrew has been digging deep into the Liferay code again

.. seriously. Someone should buy me a mining hard hat and a shovel.

David H Nebinger:

rotfl... That's where I've been on LR7, mining nuggets of truth (as much as I can) from the milestones...

Snow White should be along any time now to fetch her true love's kiss

[Meera Prince, geändert vor 8 Jahren.]

Hi when we add some file or document in the DL we can get webdev url nd download url.

When you hit this url in broweser its downloaded automatically its default behaviour.
If its pdf then it will be viewing in the browser because browser can able to show pdf.other than pdf all extension files will be downloaded when you hit.
Css nd js file you can use with link src nd script src then it can be loaded and css and js available for the page

Regards
Meera Prince

[Andew Jardine, geändert vor 8 Jahren.]

Hey Meera,

That for replying but that much I already know -- see my reply to David for further details as to specifically what I am trying to do.