-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
createPreviewUrl dynamic path and normalize path bug #27
Comments
#21 is now updated and merged, cft. last commit. The Java connector now will set the path property to a ready-to-use URL. On the client side I use at the moment just:
If the PR is accepted, I would like to add a configuration key e.g. named previewUrl, which, if true, would just return the server path value (with prefix / i.e. fileRoot), otherwise the default. |
Great, thanks.
So the only right way fot any connector is to implement "readfile" method, which reads file and outputs its content. |
I could do this - sorry, I missed this. Preview is now readfile, I have to update the Java Connector. The case is, that I do not always want to export (select) the proxy url (readfile URL). You could think of it like, that you release this image may be by copying it into a public folder. Then I have not to do always check and restrict access, it´s released. I have to update the Java Connector to get the two settings working both, the default setting with relative paths in path, and the one I described with direct URL (using document root in config file). Do you think, it makes sense? |
I guess it's a bad idea to use direct urls (relative or absolute) to get image or media files. It leads to the situation when the frontend should expect various results in response and handle each case in a different way. This makes things more complicated. Frontend won't be able to handle cases for each connector. Eventually we will get a mess in the code. I understand that you may have images in a public folder. That is my case in fact. All files which I have on my local machine and demo page are in a public folder and may be reached by a direct URL. And that's how the FM was arranged before. But, since we decided to bring more standards in FM and make it more unified, I also had to modify PHP connector to handle Take the idea that all logic (which file to read and the way to output it) should be perfomed in the |
Hm, I understand. There has been some discussion around this, I assume. Neverthelesse I´ll update the connector, but try to keep the direct mode, as it is the default for many instances we use - with backward compatibility and URL consistency some reasons behind. Is this ok? |
I would prefer to get rid of direct URL completely. There are no working connectors now except PHP. Java and Node.js are in development now. Any other connectors have to be rewritten and no need in backward compatibility. Let's do in the following way. You implement
|
Original discussion on standards and unification is in #31 FYI |
Hey, thanks! I do my best to separate it. I´ll include just the crude one without direct URL support in the PR, but keep the extended version for later consideration, which then may become another PR. |
Yeah, that's great |
The code is updated and it´s working apparantly. I kept the (two) methods required for direct URL as dummy indirections, but otherwise removed anything, so it´s much cleaner. If the community comes later up with another solution they could just removed them, without any side effects. This way I can just extend the existing RichFM.java. |
Thank you, I am going to merge it up to next week. |
Solved with the RichFilemanager release v.2.0.0. Check this post for details. |
Cft comment in #18.
The text was updated successfully, but these errors were encountered: