Question: JSON structure for recursive file searching

[ShortBusKing]

I use the following server-side connector (check one):

• ASP.NET Core connector by sinanbozkus

My familiarity with the project is as follows (check one):

• I have used the project extensively, but have not contributed previously.

---

Hello,
Could you please provide the format of the expected JSON file when performing a recursive search from the server? I can't seem to figure out what is expected.

Thanks!

[psolom]

It's outlined in the Wiki (check "response example"):

https://github.com/servocoder/RichFilemanager/wiki/API#get-seekfolder

[ShortBusKing]

Thanks for the link!
I was able to get recursive search setup for the .NET Core connector. It looks like this when searching for 'png'.

Is there's someway to display folder name along with the file names? If there are copies of a folder then searching recursively becomes less helpful as seen in this case:

Could we add a folder field or do you have some suggestions?

Also here is the JSON I'm generating from the connector. Does it look as expected?

{"data":[{"id":"d/Step1ofTOC.png","type":"file","attributes":{"name":"Step1ofTOC.png","path":"d/Step1ofTOC.png","readable":1,"writable":1,"created":1524074639,"modified":1524074639,"size":802408,"extension":"png","timestamp":7081.5458344}},{"id":"d/step2.png","type":"file","attributes":{"name":"step2.png","path":"d/step2.png","readable":1,"writable":1,"created":1524074641,"modified":1524074641,"size":48820,"extension":"png","timestamp":7079.46785}},{"id":"d/Step2ofTOC.png","type":"file","attributes":{"name":"Step2ofTOC.png","path":"d/Step2ofTOC.png","readable":1,"writable":1,"created":1524074643,"modified":1524074643,"size":200595,"extension":"png","timestamp":7077.3498296}},{"id":"d/step3.png","type":"file","attributes":{"name":"step3.png","path":"d/step3.png","readable":1,"writable":1,"created":1524074645,"modified":1524074645,"size":79314,"extension":"png","timestamp":7075.0208004}},{"id":"d/Step3ofTOC.png","type":"file","attributes":{"name":"Step3ofTOC.png","path":"d/Step3ofTOC.png","readable":1,"writable":1,"created":1524074647,"modified":1524074647,"size":200595,"extension":"png","timestamp":7072.964784}},{"id":"d/step4.png","type":"file","attributes":{"name":"step4.png","path":"d/step4.png","readable":1,"writable":1,"created":1524074649,"modified":1524074649,"size":127988,"extension":"png","timestamp":7070.8707669999994}},{"id":"d/Step4ofTOC.png","type":"file","attributes":{"name":"Step4ofTOC.png","path":"d/Step4ofTOC.png","readable":1,"writable":1,"created":1524074651,"modified":1524074651,"size":176029,"extension":"png","timestamp":7068.8017412}},{"id":"d/step5.png","type":"file","attributes":{"name":"step5.png","path":"d/step5.png","readable":1,"writable":1,"created":1524074654,"modified":1524074654,"size":92869,"extension":"png","timestamp":7066.4697172}},{"id":"My folder/7255-dizzy-face.png","type":"file","attributes":{"name":"7255-dizzy-face.png","path":"My folder/7255-dizzy-face.png","readable":1,"writable":1,"created":1522104091,"modified":1522104091,"size":12332,"extension":"png","timestamp":1977629.1790007}},{"id":"d/png","type":"folder","attributes":{"name":"png","path":"C:/Code/richFileManager/API.NetCore/wwwroot/ContentLibrary/d/png","readable":1,"writable":1,"created":1524075605,"modified":1524075605,"timestamp":6114.7626850999995}}]}

[psolom]

Full path in listview upon search is possible. This mostly relates to the template. Open index.html file, find the following line:

<span data-bind="text: koItem.rdo.attributes.name"></span>

And replace it with:

<span data-bind="text: $root.searchModel.value() ? koItem.rdo.id : koItem.rdo.attributes.name"></span>

You are able to modify output as you do in a regular JS code. For example, you can remove a leading slash as: koItem.rdo.id.substring(1)

The drawback is that index.html is under git control, so make sure it won't be overwritten when you update RFM package.

[psolom]

I found responsiveness delay in items rendering while server-side search in case you modify path, like in my example. Fixed with the latest commit. Now use searchModel.isRendered() instead of searchModel.value():

<span data-bind="text: $root.searchModel.isRendered() ? koItem.rdo.id : koItem.rdo.attributes.name"></span>

[psolom]

Also here is the JSON I'm generating from the connector. Does it look as expected?

Mostly. As you can see in the Wiki the "id" property string is prepended with a leading slash across all examples. I can't remember for sure if this is a key point, but it may potentially cause issues.

On the other hand if all others API method return "id" property without leading slash and all RFM actions work good, you could leave it as is and watch how it will go.

[psolom]

I was able to get recursive search setup for the .NET Core connector.

When you complete I would expect you provide a PR with features that currently missed in ASP.NET Core connector, like recursive search. Thanks for your efforts.

[ShortBusKing]

Sorry for the delay, I've been away.

In response to:

You are able to modify output as you do in a regular JS code.

I had prototyped having a full path as pictured here. I'm simply using the koItem.rdo.attributes.Id field. FYI, I have added the first character slash as requested which is not in this picture.

As an alternative solution, I was wondering if we could add a column in the template when recursive search is enabled. Something like:

<span data-bind="text: koItem.rdo.attributes.**FolderName**"></span><span data-bind="text: koItem.rdo.attributes.name"></span>

Per the wiki, we don't have a variable FolderName, maybe something like something like this pseudo code:

<span data-bind="text: $root.searchModel.isRendered() ? koItem.rdo.id.replace(koItem.rdo.attributes.name,"") : "/"></span><span data-bind="text: koItem.rdo.attributes.name"></span>

For the connector, I will make a PR soon with a list of improvements. Thanks for your efforts as well.

[psolom]

Do you mean to add a separate column to display folder name?

Does this make any sense? Don't you satisfy with how the paths are represented at your screenshot?

For the connector, I will make a PR soon with a list of improvements.

Have just merged your PR. Thanks a lot!

[ShortBusKing]

Some note on the current state of the connector for clarity.

1. The .Net Core connector does not return full paths as pictured above when recursive searching and can return "duplicates" as in post 3.
2. The .Net Core connector does not return image dimension parameters. While possible, the .Net Core support for this functionality seems a bit limited.

[psolom]

1. I am still confused what is wrong with the image, provided above? Files paths are prepended with folder names and seems fine. Or do you mean a default template, without this workaround implemented:

<span data-bind="text: $root.searchModel.value() ? koItem.rdo.id : koItem.rdo.attributes.name"></span>

2. Not so important I believe.

[ShortBusKing]

You are correct that this is not a large issue. However, this doesn't match how Window or Linux/Unix systems generally return data in a separate column when searching recursively. It might also be helpful to be able to sort by folder paths and then have the files display in alphabetical order.

Linux/Unix (Please notice the 'Path' column):

Windows (Please notice the 'Folder' column):

IMHO, the Linux/Unix example with the 'Path' column is closest to what I believe we need.

If we need another parameter returned from the .Net Core connector, I can take that task on, but I'm not sure about the other connectors.

[ShortBusKing]

FYI, when recursively searching the .Net Core Connector, I've currently coded it to return data without any folder information. This is an example:

[psolom]

I see. You tend to implement new column to display the folder path as it's at your screens above. Well, this can make sense. I don't think this require any additional data from the connectors. We can split the id parameter and fetch the path without filename.

For instance if the id param reads as: /images/isons/camera.png

Then fetched path for new column: /images/isons

Does this match your vision?

[ShortBusKing]

Yes, your understanding is correct and this will match with my version of the connector.

Thanks!