Display a filename for the card type:File+discussion

Interesting!  Several responses:

1. The core issue may be that wagn is doing a poor job of handling files for which no mime type is known.  If that's the case we should ticket and fix.  For example, if Wagn (or the "paperclip" gem it uses doesn't know about .sql files, then it should just send it as a standard download in file disposition.)  I'm not sure that's currently done well.
2. it shouldn't be too hard to create a view of just the extension if that's what is needed
3. I'm not sure I entirely get what you're seeing yet.   You said that when you tried raw view you got a new card for editing?  That seems very strange.  Here's what I see with raw view:

{{wagn for geeks|raw}}:

(my_bucket)/20636/660268.pdf

 

 

The first line is the original file name, and that file extension is used when wagn looks up the actual file.

 

Note that there is also a "source" view which will include the full web address (which, as it happens, does not actually directly indicate the file storage directory; there is a translation layer).  But, because the file extension is derived from the original file extension, it should generally be the same.

 

{{wagn for geeks|source}}:

 

https://nyc3.digitaloceanspaces.com/decko/files/20636/660268.pdf

 

 

 

 

 

---

clarification: I did use "preformatting" on the raw view to make things pretty here, but I really don't get why you'd see a new card for editing. is that something you can reproduce here?

  --Ethan McCutchen.....2013-02-14 21:14:15 +0000

---

I thought it is difficult to get it from what I have written but you were quite close Ethan.

 

This is how it looks when a file is uploaded:

 

This is when you create the new card with the field exposed:

 

 

One more thing which concerns me. If you would get huge number of files - lets say ten thusand in a year or so. Would not that slow down Wagn? If you have all the files (small ones) in one directory it can be quite slow to find the one file you are searching for.  One solution that comes to my mind is to create a folder structure like (0 1 2 ... A B C ... Z) where you would store all the files starting with certain character (of course stripping any potential accented characters).  This should last much longer than just a flat structure.

 

P.S. File size display would be also nice feature so the user knows how long it will take to download it.

 

  --Tukanos.....2013-02-15 10:56:03 +0000

---

I'm guessing the number at the end - 3060 in this last example - is the file size?

  --John Abbe.....2013-02-16 00:34:16 +0000

---

Right, that's the file size (though it's admittedly not super useful yet).

 

Re storage, the urls are not directly representative of the file storage. See implement password security for files. Though the point is still valid, because there would be id-based directory per file. Still, since they're all numerical, that will be easy to solve while maintaining our clean, simple urls.

 

I'll come back to your main question soon; suffice it to say that one's trickier :)

  --Ethan McCutchen.....2013-02-16 02:48:47 +0000

---

I see, did not notice the number (no unit there :)

 

I shall read the security for files to see the details. I completely understand that my main question is harder as it is a concept of showing the information without user editing it.

 

From my point of view it would be best if there would be a configuration for a card something like "display-only". The question is how hard is to implement it or how does it fit the overall schema.

  --Tukanos.....2013-02-16 09:31:45 +0000

---

there is a way that this is possible now. you can create a virtual "raw view" card. something like this:

name: raw view+*right+*content, content: {{_left|raw}}

 

then in your *content rule for the card above, include {{solution script+*raw view}}.

 

since virtual cards are not shown in new/edit view, something like that should work.

  --Ethan McCutchen.....2013-02-16 15:18:38 +0000

---

Good idea with the virtual cards. I'll try it out on Monday. However, more structured information about the file would be the best way. Thank you for the tip.

  --Tukanos.....2013-02-16 20:19:20 +0000