attachments1Add my vote for this tag user_interface1Add my vote for this tag create new tag
, view all tags

Feature Proposal: a way to get the number of attachments

I want to display the number of attachments to a topic. I propose a new variable %ATTACHMENTCOUNT{}%, with optional parameters topic and web.


Scenario 1: the Dakar twisties on the attachment table used to show the number of attachments. The prototype javascript that was used to calculate display the number of table rows has been removed. It would be good to have a native variable to access the number of attachments instead of this workaround.

Scenario 2: on a projects site it would be very useful to show the number of attachments of each project page. For instance the project homepage would show the number attachments with each topic.

-- ArthurClemens - 23 Feb 2006


For the attach template a variable ATTACHMENTVERSIONCOUNT would be useful as well.

-- ArthurClemens - 24 Feb 2006

Geeting at the attachment could is useful, as well as actual attachment meta data (name, size, date etc.)

Instead of introducing many new specialized VARIABLES I would prefer to create a solid ContentAccessSyntax.

-- PeterThoeny - 27 Feb 2006

Scenario 1: For TWiki 4.0.3 this has been solved using javascript.
Scenario 2: still open request.

-- ArthurClemens - 30 Jun 2006

This feature will need to be calculated on each view of topics with attachments.

And getting number of revisions and calculating number of attachments on the server side will add additional load and execution time per view.

TWiki is too slow. Is this feature really so important that it is worth extra load?

I have not seen many proposals that could speed up TWiki but we keep on creaping features into TWiki and the amount of javascript, css grows and grows and grows.

What is the user case for adding these features - server side or client side? We have to watch out for adding features that are just nice to look at but do not really add any value.

I could be wrong with this one but at least think carefully before adding more and of we add it the code must be very fast.

-- KennethLavrsen - 01 Jul 2006

The number of attachments can be "cached" in META. it can be updated either when a new attachment is added or when the "auto-attach" code detects a new attachment. With this number cached, the performance is not impacted. But you have a very valid point. TWiki4.0.3 is stable enough to start thinking about improving performance only before adding more features to it.

-- RafaelAlvarez - 01 Jul 2006

We are digressing. But I would like to add: we can add new features if the impact on performance is negligible.

-- ArthurClemens - 01 Jul 2006

I would say yes if it is done with performane in mind. In this particular case, we could add one generic %ATTACHMENTINFO{ function="count" }% variable. It can be enhanced later with %ATTACHMENTINFO{ function="list" format="$file ($size)" separator=", " }%, %ATTACHMENTINFO{ function="file" format="$size" }% etc, ready for use by ContentAccessSyntax.

-- PeterThoeny - 02 Jul 2006

An alernative is to use a SpreadSheetPlugin CALC to calculate the size of the table preceeding the CALC.

-- PeterThoeny - 02 Jul 2006

Another alternative it to write an AttachmentInfoTag, which I've done. It'll be uploaded to the TWikiWithTags branch tomorrow. It only supports function="count" atm, since that's the current request, but obviously it can be extended.

-- MeredithLesly - 03 Jul 2006

I prefer one variable for all attachment info over many vars since it is less expensive to parse.

-- PeterThoeny - 03 Jul 2006

I said "atm". If I were only going to implement the one function I would have named it AttachmentCountTag, after all.

I'm not sure what you mean about being less expensive to parse, however. Could you elaborate?

-- MeredithLesly - 03 Jul 2006

When you define ATTACHMENTCOUNT, ATTACHMENTLIST, ATTACHMENTFILE, ATTACHMENTSIZE, ATTACHMENTCOMMENT, ATTACHMENTAUTHOR, ATTACHMENTETC you need to parse many variables on every topic, regardless if the variable is used or not. If you define just ATTACHMENTINFO and delegate the functions into the variable you need to parse the top level only once. The second parse inside ATTACHMENTINFO does not affect the overall performance of the system. In other words, for perfomance avoid adding many case statments in the top level switch.

-- PeterThoeny - 03 Jul 2006

I don't believe that's the case. Only tags that are used in a topic are "parsed". In fact, it's probably slightly faster to have more tags than to have to parse the insides of fewer tags and have a "switch statement" (not that perl has those, of course). But remembering that many tags is hard on the user, so adding lots of tags, even if a tiny bit faster, isn't worth it.I don't understand where you're coming up with all of these names, however. AFAIK, no one has proposed having all of those, so your point would appear to be moot.

-- MeredithLesly - 03 Jul 2006

Call it moot if you wish. We need fine grained access to content once we have ContentAccessSyntax, which is like a DOM.

-- PeterThoeny - 03 Jul 2006

I never suggested that the functionality not be added. However, the expressed fear of a bezillion tags being added appears to come out of the blue, as I don't see any suggestion to do that in the above discussion and feels like an unnecessary distraction.

-- MeredithLesly - 03 Jul 2006

It appears there is a wish to display more kinds of info on attachments. I suggest we create a new topic for that.

-- ArthurClemens - 03 Jul 2006

Fine with me. I was just trying to solve your problem.

-- MeredithLesly - 03 Jul 2006

Yes, this topic is fine for discussing attachment count.

-- ArthurClemens - 03 Jul 2006

I just stumbled across this and thought I'd post a note that DBCachePlugin now offers multiple options to list information about attachments including their count.

-- LynnwoodBrown - 12 Apr 2007

Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r22 - 2007-04-12 - LynnwoodBrown
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.