Use of file manager extension

Help / Discuss
1

Hello everyone,

I’ve seen the “File Manager” extension and would like to use it in my XWiki.

I have a question about how to use the extension: Can I link attachments that I place in the File Manager to XWiki pages?

Or, to put it another way, can I make attachments that I add to an XWiki page visible in the File Manager, so that the attachment only exists in one place in XWiki?

Thanks in advance for your help.

Regards, Stefan

2

I’d say yes. They are standard attachments.

I think the doc at http://extensions.xwiki.org/xwiki/bin/view/Extension/File%20Manager%20Application is missing some info about how the File Manager maps its tree to wiki pages.

I don’t know that app so I can’t answer your question. Maybe it requires some xobject to be added to a page to materialize an attachment to be displayed in the File Manager UI. Or maybe it’s based on finding some pages inside a technical dedicated File Manager space. Maybe @mflorea knows.

Thanks

3

That. When you add a file through the File Manager Application, it creates a page inside the File Manager space, with some metadata to mark it as a “file” page, and with the actual file attached to that page. So the File Manager application doesn’t look for files (attachments) anywhere in the wiki. It only looks for files that were added through the File Manager UI, and so which have a dedicate “file” page inside the File Manager space. You can have multiple file manager spaces, called drives, but that’s about it.

Hope this helps,
Marius

4

ok I guess that’s why it looks in a specific space. Otherwise, the metadata added would have been enough, independently of the location of the page in the wiki.

Thus to the question:

the answer is no :slight_smile:

You’d need to go through the FM UI or move the page inside a FM space and add the required metadata (the UI is recommended).

5

No, because there’s also a hierarchy of files. Files are organized in Folders. Each Folder is also a page with some metadata. Keep in mind that the File Manager was implemented when we didn’t support nested pages. So it’s not enough to mark a page as “File”, you also need to put it inside a Folder. The File Manager is looking for orphan files (that have no folder associated), but only inside the drive.

6

Hello Community,

Thank you very much for your answers.

OK, if I understand correctly, it is not possible to link attachments from other XWiki pages using the File Manager.

I am looking for a solution that will allow me to display certain attachments from different pages together on one page. That’s why I thought I could use the File Manager extension for this.

For example:

In XWiki, there are various pages with fillable PDF files attached. To avoid having to search for and open these pages every time you want to access the PDF forms, I would like to create a page (I’ll call it “fillable PDF files”) that lists all the important PDF form files. However, there should only be one original so that any changes to the original PDF file are also available directly on the “fillable PDF files” page and you don’t have to maintain two or more versions of the same PDF file.

Is there a solution for this?

Regards, Stefan

7

It depends on how you define “important”.

The simplest solution, if I understand your need correctly, is to simply create a page with hard-coded links to the important PDF attachments. But it’s not easy to maintain. You need to remember to add / remove the link whenever you add / remove an important PDF.

Another solution, that is easier to maintain, is to define a xclass and then mark pages that have important PDF files with an object of this xclass. You may want to check the FAQ Tutorial if you want to go in this direction. If you do, then you need to decide whether you allow having multiple PDF files attached to the same wiki page or not. If you allow that, then the xclass might need a property to indicate the file name of the PDF attachment. With this in place, you could use the Live Data macro, or the Query Module API to list all the important PDF files.

Another solution, less clean, is to use a naming convention for important PDF files, e.g. by prefixing or suffixing them, and then use either the Query Module API or the Solr Search API to retrieve all the PDF attachments that match the pattern and list them on that page.

Hope this helps,
Marius

8

Hi Marius

Thank you very much for your reply and the various solutions you suggested.

“Another solution, that is easier to maintain, is to define a xclass and then mark pages that have important PDF files with an object of this xclass. You may want to check the FAQ Tutorial if you want to go in this direction. If you do, then you need to decide whether you allow having multiple PDF files attached to the same wiki page or not. If you allow that, then the xclass might need a property to indicate the file name of the PDF attachment. With this in place, you could use the Live Data macro, or the Query Module API to list all the important PDF files.”

That sounds like an interesting solution for me, but I have absolutely no idea how it works with XWiki classes and objects, so I’ll have to familiarize myself with them thoroughly first.

I took a look at a few sample pages with the live data macro, and the output with the live data macro looks very appealing.

Regards,
Stefan

9

Hi,

I have now opted for a simple solution using tags so that normal users can also work with it quite easily:

I have created a new page called Important Documents.
Using a live data macro, I display all pages that contain the tag “important.”

{{liveData filters="tags=important&tags=Important" id="documents" properties="doc.title,doc.fullName,tags" showPageSizeDropdown="false" source="liveTable" sourceParameters="className=XWiki.TagClass&translationPrefix=platform.index."}}
  {
  "meta": {
    "propertyDescriptors": [
      {
        "id": "tags",
        "visible": false
      }
    ]
  }
}
{
  "columns": [
    { "id": "doc.title", "name": "Title" },
    { "id": "doc.fullName", "name": "Site" },
  ]
}
{{/liveData}}
1 Like