FileTreePanel Forum Thread

View Sources:
filetree.html
filetree.js
filetree.css

Silk Icons

Other Extensions and Plugins

StumbleUpon Toolbar

FileTreePanel Client-Server Interface Specification

FileTreePanel is client-server application where client (browser) provides the user interface (UI) which displays the tree and context menu, handles drag & drop operations, etc. The filesystem that is displayed and managed by the UI is stored on a server.

Therefore, we need some communication layer between client and server. Client sends a command to server, server processes this command and responds with a result. Client in turn processes the response and display results.

All this communication is running in the background by Ajax (XMLHttpRequest) calls. The XMLHttpRequest is not used directly but the Ext JS - JavaScript Library ajax layer is used for this purpose.

Client requests data from server with standard POST method and server is expected to respond with JSON (JavaScript Object Notation) string and appropriate HTTP headers.

Example of rename command:

POST Request:

    cmd rename
newname root/abc.txt
oldname root/a.txt

Response headers:

Content-Type: application/json, charset=utf-8

Response content of success:

{"success":true}

Response content of failure:

{"success":false,"error":"Cannot rename file root/a.txt to root/abc.txt"}

The response headers are same as above for all responses, unless mentioned otherwise, and they are therefore omitted from the following specification.

Paths

The server side filesystem that is managed by FileTreePanel starts at a directory that is defined by the server for security purposes. Client cannot change its root by any command.

Example of filesystem:

Server viewpoint:

/data/userfiles/root_for_client/dir1/file1
/data/userfiles/root_for_client/dir1/file2
/data/userfiles/root_for_client/dir2/file1
/data/userfiles/root_for_client/dir2/file2

Client viewpoint:

root_for_client/dir1/file1
root_for_client/dir1/file2
root_for_client/dir2/file1
root_for_client/dir2/file2

Now, when client asks server "gimme nodes in root_for_client" the server prepends absolute or relative root path, reads relevant part of the filesystem and returns nodes. In our example, the server would prepend /data/userfiles/ to each client's request.

It is server job to handle invalid requests or requests that can be potentially insecure like ones starting with / or .. The same must be true for all commands sent from the client.

 

Commands

get command

Request:

 cmd get
path root/a

Response:

[
{"text":"b","iconcls":"folder","disabled":false,"leaf":false},
{"text":"a.txt","iconCls":"file-txt","disabled":false,"leaf":true,"qtip":"Size: 1047552"}
]

Note: The response above is shown in four lines only for the purposes of this specification to be more readable by humans. The line breaks must not be sent from the server as a part of JSON string.

In the above example, we request server to deliver nodes of path root/a and it responds with one directory named b and one file named a.txt. "text":"b" in the response is the name of the directory and "text":"a.txt" is the name of the file. Note that server sends just names, not full paths of nodes.

"iconCls":"file-txt" in the response is to display correct file type icon by client and "qtip":"Size: 1047552" is optional text for file tooltip. leaf property distinguishes files from folders and disabled is true for read-only files or folders.

For the other possible properties that the tree can process if they are sent from the server consult Ext JS Documentation.

rename command

Request:

    cmd rename
newname root/abc.txt
oldname root/a.txt

Response of success:

{"success":true}

Response of failure:

{"success":false,"error":"Cannot rename file root/a.txt to root/abc.txt"}

Error message text in the above example is not obligatory - server can send any kind of an error message, e.g. localized text.

 

newdir command

Request:

cmd newdir
dir root/a/b

Response of success:

{"success":true}

Response of failure:

{"success":false,"error":"Cannot create directory: root/a/b"}

 

delete command

Request:

 cmd delete
file root/a/b

Response of success:

{"success":true}

Response of failure:

{"success":false,"error":"Cannot delete: root/a/b"}

 

upload command

Request:

 cmd upload
path root/a

Response headers:

Content-Type: text/html, charset=utf-8

Response of success:

{"success":true}

Response of failure:

{"success":false,"errors":{"ext-gen524":"File upload error."}}

File uploads are handled differently. First of all, server has to respond with text/html content type and, in the case of failure, it has to respond with errors object with an error message for each uploaded file. Properties of errors object are <input type="file"> field names. These names are auto-generated and they are available at server while processing the file uploads.

Server has to ignore NO_FILE error and it has to report "success":true only if all files have been uploaded successfully.