Changing Document Library URLs

[11年前 に Roger Wilson によって更新されました。]

Hi there,

I've recently been asked to change how document links are handled and processed in my application.

Currently these links take the general form:

http:// {HOSTNAME} /documents/ {groupId} / {filename} / {guid}

Where the values in {} are placeholders, and 'documents' is literally written in the URL. There's sometimes another intermediate value between groupId and filename, but that's generally how they appear.

I've been asked to change this to a form that looks like the following:

http:// {HOSTNAME} /documents/ {groupId} / {guid} / {filename}{extension}

That is to say, looking for the guid and the filename to switch places in the url placement, and then the extension to the file in question appended onto the end.

This strikes me as a daunting request. I can see overriding how a url displays in a hook easy enough, but then I'd have to change how liferay is reading the URL itself as well. That might not be so simple.

Is this possible? What would be involved? As far as I can see, there'd have to be a hook branching from docroot/META-INF/custom_jsps/html/portlet/document_library, but I'm not sure what .jsp or .jspf I'd want to look into just yet. And I have no idea what I'd want to look at in order to flip the values. Would an extension be required for that? If so, what would I most likely be changing? I get VERY nervous at the idea of mucking around with extensions since they can't really be uninstalled. Plus paring down where the extension would be stored in the DB tables, but that's less of a worry.

[11年前 に Roger Wilson によって更新されました。]

Hi all,

Still having problems with this.

To make clear for anyone reading, the issue is not so much the restructuring of the URL -- I've set up the link to change easily and I can get the title and extension from the given DLFileEntry easy enough. The problem is getting liferay to recognize the new link and deliver us to the same place. As it is once we put in the new link we predictably get routed to an error page.

Someone had suggested I look into struts in liferay or creating an ext, but there's been no certainty on what the best way forward is.


Thanks again.

[11年前 に Roger Wilson によって更新されました。]

After some further research, I found out that if you change the URL from this, which is the present format:

http:// {HOSTNAME} /documents/ {groupId} / {filename} / {guid}

To the following:

http:// {HOSTNAME} /documents/ {groupId} // {folderId} // {filename}

Will also work. Since the key is really to have the filename on the end followed by an extension, this would be a vast improvement. I've tested this out and it seems to work just as well, even after I change the title of the document.

I'm new-ish to liferay development, but I figure if I change the URLs to this and then append an extension, is there some sort of event that I can fire that will then ignore that appended extension and redirect to the URL as listed above? I'm new with struts, so hopefully that would hold the key: I'd just need something that fires off from any link click, and would then identify by its value (the presence of "/documents/" that it was a link associated with the document library -- in which case it would redirect to a substring of everything prior to but not including the last "." in the url.


but, MORE IMPORTANTLY:

If I were to get that working, that would resolve half of my problems. The other half is that CKEditor would continue to work as-is, with the format of the URL unchanged. Is there any way I would be able to change either CKEdit or Liferay core code so that the URL that appears after selecting a resource from "browse server" (the interface that runs off of /html/js/editor/ckeditor/editor/filemanager/browser/liferay/browser.html) comes up in the format I specify? Not to mention I would have to try to grab the file extension and place that in the URL as well (which hopefully a server-side event can then toss aside upon "click()", as mentioned above.

[11年前 に Roger Wilson によって更新されました。]

Taking a step back and looking at this, I decided that all that really had to be done fell into two categories:

1. Change my portlet code accessing the document library where necessary
2. Change existing code accessing the document library where necessary

And when I say 'existing code', the only example that really stands out to me is the file management in ckeditor (fckeditor) when creating a link, which allows you to browse through the document library.

So I wanted to change the link that this file browsing widget spits out to be saved. I decided to bypass the javacript code of ckeditor itself and track the AJAX code into the system. This led me to the following namespace, which seemed relevant:

com.liferay.portal.editor.fckeditor.receiver.impl

There's about 4 classes to this namespace. The ones I've looking at now are baseCommandReceiver, documentCommandReceiver and pageCommandReceiver, since these three all have a function called "getFilesAndFolders", which would seem to be the point of entry.

I'm struggling now with trying to set up the extension project to tap into this method execution. I've never done these before. I consulted the documentation and for a test added in a portal-ext.properties file into the project's ext-impl/src folder, and applied a new setting that I didn't reference in my main properties file. Upon restarts and deploys, this seemed to work. So far so good.

From there I then added in a package into the same folder since documentation seemed to indicate the java files should reside here as well. I added in a package and to be certain, created three classes that extended the three classes mentioned earlier, overrode the method I wanted, and for now just called the super from the base class. So the code for a given one looks like the following:

package com.wilson.liferay.commons.editor.fckeditor.receivers;

import com.liferay.portal.editor.fckeditor.receiver.impl.DocumentCommandReceiver;
import com.liferay.portal.editor.fckeditor.command.CommandArgument;

import org.w3c.dom.Document;
import org.w3c.dom.Node;

public class wilsonDocumentCommandReceiver extends DocumentCommandReceiver {

	@Override
	protected void getFoldersAndFiles(
			CommandArgument commandArgument, Document document, Node rootNode) {
		
		System.out.println("This is working!");
		System.out.println("before call to super...");
		
		super.getFoldersAndFiles(commandArgument, document, rootNode);
		
		System.out.println("... and after call to super");
		
	}
	
}

But naturally, I can't see any of my print statements. I also try commenting out the call to the super, but everything still works, when I'm at least trying to get it to break when interacting with ckeditor. Doesn't seem that this part of the extension project is executing, so I'm not sure if I'm doing this right at all.

[11年前 に Roger Wilson によって更新されました。]

This has now been resolved.

Turns out that I am not able to do any sort of overriding or inheriting of classes within an EXT: everything must have exactly the same name as before. However, the class referenced is exactly the one I needed to override in order to get ckeditor pulling the information I wanted.

For those interested, the key here is that you need to keep the guid in the same relative place in the URL, but the presence of the filename actually does not matter. Neither does it matter what you append to the end, so long as the guid's place in the URL is preserved. Therefore a link that generates as per the following:


/documents/19/0/NewYork+Fire+3.jpg/b6c657b4-ccd8-444c-8ab3-2932fd7fc30f

can become the following and still work:

/documents/19/0/-/b6c657b4-ccd8-444c-8ab3-2932fd7fc30f/NewYork+Fire+3.jpg

Note the "dash". This could be anything, but the importance is that the place in the URL is preserved. This can be accomplished, for documents, in the fckeditor.receiver classes mentioned previously.