Item10051: There is no way non-Meta to keep an attachment comment using Func::saveAttachment

Foswiki::Func::saveAttachment, and the code behind in Store / Meta (1.0 or 1.1) default the options hash values for comment/attr etc to and empty string.

this, combined with the lack of a Foswiki::Func::getAttachmentMeta() means an Extension developer (or the WebDAVContrib ) cannot avoid using Meta.pm to get the information needed to leave the previous values alone.

given that PUT should set the entire state of the new object, this makes sense in the Foswiki::UI::Upload code, but becomes a little difficult elsewhere.

I guess that there are 2 things we could do -

• change foswiki so that an undefined attribute uses the previous one (convinient, but means transactions are dependent on the n-1 state)
• provide a Foswiki::Func to get the info

I am leaning towards the second, and am wondering if we can 'simply' amend Foswiki::Func::readAttachment() to return the attributed hash if used in a list context. That would mean that all original users of the function continue to work, but we give more info to those that need it.

I need this to get WebDAVContrib working as expected for a client on 1.0.10, so whatever fix we decide is 'right' i'll be needing to maintain patches

-- SvenDowideit - 19 Nov 2010

giggle, I note that we have a Foswiki::Func::getAttachmentList(), but we don't use it in the example code for Foswiki::Func::readAttachment()

-- SvenDowideit - 19 Nov 2010

Been stumbling across this in TopicInteractionPlugin as well. So I've been falling back to using Meta to read the prev comment and hide state and only overwrite it when undefined in the request.

There are three options, not all of them are exclusive

(1) don't nuke comments if undef in hash: makes more sense -> doesn't break anything

(2) add Func to read attachment properties: attachmments are treated a bit halfhearted here -> we will never be feature complete, but hey ...

(3) make Meta a first class API ... sort of blessing plugins already using it

-- MichaelDaum - 19 Nov 2010

Making Meta a first class API is under discussion elsewhere. At this stage, I think extending Func is the way to go. A fall-back to a Meta-based solution in caller is probably the right thing to do for compatibility (or you could always monkey-patch it in to Func if it's missing)

-- CrawfordCurrie - 19 Nov 2010

Remember that API changes requires feature proposal.

Just to make sure we have as many eyes on the suggested change as possible. I have no concerns with Func update as long as backwards compatibility is maintained.

-- KennethLavrsen - 19 Nov 2010

Commenting is disabled while not logged in