Add SanitizeAttachmentName To TWiki::Func

This has been implemented for TWiki 4.2, see Bugs:Item3780 -- ArthurClemens - 18 Mar 2007

Enhancing TWikiFuncDotPm with TWiki::Func::SanitizeAttachmentName() is needed for the next release of BatchUploadPlugin, and probably by anything that needs to handle the renaming of attachments during upload.

This is likely to be a one-liner: can we include it in the interface?

I'd prefer to not have to duplicate this function.

Thanks.

-- Contributors: MartinCleaver - 15 Oct 2006

Discussion

Note. This is an extension of the TWiki API. I am assuming Martin can and will implement this himself and it is added to the WhatIsIn04x01 topic, so this falls under the 14 day auto accept period. Last date for objections or concerns is 29 Oct 2006.

-- KennethLavrsen - 15 Oct 2006

For displaying feedback on attachment renaming, see also RelayAlertsToTopicTop.

-- ArthurClemens - 15 Oct 2006

Implementation unless I hear objections will wire TWiki::Func::sanitizeAttachmentName() to TWiki::Sandbox::santizeAttachmentName() i.e.

TWiki::Func
=pod
Explanation goes here
=cut

sub sanitizeAttachmentName(...) {
   TWiki::Sandbox::sanitizeAttachmentName(...);
}

1. Write the explanation
2. To do: find and wire the args.

Anything else?

-- MartinCleaver - 15 Oct 2006

Concern raised by ThomasWeigert. KennethLavrsen moved it from WhatIsIn04x01 to here where it belongs. Please raise concerns on the discussion topics and not in the WhatIsIn04x01 which is supposed to be an index/status topic. -- KennethLavrsen

What is the happy middle ground between making an API for every TWiki Core functionality vs. never extending the API. In my plugins I have decided to reuse TWiki core functionality whenever I can reuse and just pushed for refactoring where that functionality is not generic enough. I have not asked for extensions of the Func API as there is no limit to it. Maybe, rather than extending the Func API here, we can just document all the TWiki core functions that Plugins are reusing, and give these a somewhat privileged status (more careful consideration) when making changes to them. Otherwise, I should submit all my instances of reusing TWiki core for the Func API as well, as should anybody else. There would be no end until all TWiki core is part of the Func API.

I don't think that this should be auto accepted until there is further discussion on how to avoid a slippery slope here...

-- ThomasWeigert - 15 Oct 2006 .

BTW... Presently I subvert the TWikiFunc API by calling directly to Sandbox. The alternatives are 1) duplicate the code, or 2) expose it properly.

-- MartinCleaver - 15 Oct 2006

Yes, as do I and many others... duplicating code is not good, reusing from core is what we should do... but how can we prevent that eventually all core ends up in Func API and nothing can be changed any longer?

-- ThomasWeigert - 16 Oct 2006

If this gets approved please email me. BatchUploadPlugin will otherwise continue to subvert the TWikiFunc API. Thanks.

-- MartinCleaver - 18 Oct 2006

Pushing things into Func API is a good way to discover the real needs of the TWiki API. And, in a way, the Func API serves to define the PUBLIC API of TWiki.

As soon as we condone reaching into the core to get a function things may go out of control, as not everyone is discipline enough to refactor in a proper way to make a function "publisheable". Plus, there is the "Don't Make me thing" factor (I don't need to understand TWiki to make a Plugin, I just need to understand FUNC).

But there still a question: How To Refactor The Plugin API?

-- RafaelAlvarez - 18 Oct 2006

The concern raised is a general question on the criteria to add functions to TWiki::Func. It is not directly related to this request, and should be discussed in a separate topic.

I think that TWiki::Func::sanitizeAttachmentName(...) is a no-brainer and should be added. Do not forget to bump up $TWiki::Plugins::VERSION.

-- PeterThoeny - 18 Oct 2006

OK, I support.

However, I do think we need to have some strategy on what we put into Func and what not. A bad API is worse than none as we are stuck with maintaining it. If you look through Func at this point, there are definitely some problematic functions in there, in particular those that mix meta and text.

-- ThomasWeigert - 19 Oct 2006

The situation now is that there are no objections against this proposal that stand. So the expiry date for acceptance is still 29 Oct 2006.

-- KennethLavrsen - 23 Oct 2006

Martin there were no additional objections. So you can go ahead and implement your proposed code. Remember the $TWiki::Plugins::VERSION. And maybe a unit test case or two.

-- KennethLavrsen - 30 Oct 2006

The proposer never implemented this in time for 4.1. So I have decided to defer it to 4.2. We are driving a release of 4.1 before xmas and there is no chance to introduce new features and test them in time for this. This cannot be that urgent when the proposer has not done any steps to code it. It is an accepted feature and can be checked in without further discussion for 4.2. Ie. after release of 4.1.

-- KennethLavrsen - 10 Dec 2006

Implemented, see Bugs:Item3780.

-- ArthurClemens - 18 Mar 2007

I have added unit tests.

-- ArthurClemens - 14 Apr 2007

A small change I made: preceding dots and slashes are removed from the filename.

-- ArthurClemens - 15 Apr 2007