Dev Branch - fm.js, readIcons function requires DIRECTORYINDEX on Webserver about richfilemanager

[psolom]

Hm, I see.
Actually it was handled before with the option "c" that you have suggested. Take a look the "createImageUrl" function in this commit. As you can see there was a check "file_exists(fileTypeIcon)" and it worked good, but it produced 404 errors to browser console in case there was no icon found for file type. Not a good approach I believe. That why I have decided to read the whole list of icons from the filesystem, but you are right, it's not reliable way. There is option "d" - we can list all file types which have icons in config file, but of course it would be better to get the icons list dynamically somehow.

[gmkll]

Hi @servocoder, yes, the .png files in images/fileicons could be set as default. Only if no match in fileIcons (and no match e.g. in "notFoundFIs", see below) an ajax request (with timeout) would be triggered and the result set into fileIcons if found. Otherwise (404/ajaxError) the fileType is marked as not found in an array e.g. named "notFoundFIs". Then this test would applied before triggering. This is kind of incremental dynamic and may be I think the best we can get from the client side.

[psolom]

I don't think we need any ajax requests if we are going to list all possible filetype icons (see images/fileicons) in the config file. If there is no match in the list then default icon is applied. Of course we should keep the list up to date, not so flexible though. Perhaps I misunderstood your idea. What do we need ajax requests for, in the case I have described?

[gmkll]

your are right, keep it simple, I agree!

[psolom]

Hi @gmkll !
The issue is supposed to be fixed at the "dev" branch. I have moved all grid view icons paths to css, so there is no any conjuction with js side now. I would appreciate if you check it out and leave a feedback.

[gmkll]

I skimmed the current dev branch (new version, see below), but detected (or was stopped by) some changes after merge pull #49. I think there are changes on the backend side also (I not inspected all PHP changes). E.g. the (new) resourceobject is expected to have an"attributes" JSON object (was Properties, as still refered to in the API), an id (was Path?), which I never realized before, ....

I´m comparing, what was version 1.0.4 with current version 1.0.6, which is also mentioned in filemanager.config.default.json, but I think this has to be updated to at least version 1.0.7 now. To handle API (breaking!) changes I would suggest to add this versioning to the API as well, which should be consistent with (or mapped to) the version in the JSON file. Otherwise it would be difficult to understand, what´s new/changed.

I stopped at this point..
Sorry, if I missed something?

[psolom]

Oh, you use Java conneсtor, how could I forget.
It will require some changes in terms of API responses. You could find the discussion about API standardization at #37. The good news is that responses for all requests now looks similar, so that it's much clear at the moment. Of course the new API should be well described, so I will do that and come back when it's ready. Thank you for your time.