Tags:
create new tag
, view all tags
On CommentPluginDev, I've just written:

If the appendTopicText function that I wrote on FuncDotPm was implemented, it would not be necessary to "Remember to refresh before you comment" and "a plugin to accept input from e-mail" would be easier.

In fact, the latter problem has been solved a couple of times, once in the MailInAddOn and again in MailToTWikiAddOn; both times the common requirement is to be able to not have to know what was on the topic before adding some more and to have the topic locked for the minimum amount of time.

I therefore submit the patch attached for inclusion in TWikiAlpha

-- MartinCleaver - 03 Mar 2004

should the implementation of this go into StoreDotPm?

-- SvenDowideit - 04 Mar 2004

There are several issues I see with this patch that need to be resolved...

  • The documentation says that an empty string is returned for success, but the actual string returned is "ok". An empty string is probably the better choice as it has a different truth value, so can be checked more easily.
  • The documentation says that oops URL's are returned, but instead short text error strings are returned. Generic error strings aren't very useful because its a) difficult and error-prone to programmatically check for errors, and b) the error message are typically uninformative to users. Make the function return oops URL's as documented, or change it to return a list of ($status, $shortmsg, $oopsUrl) or similar, e.g. did the function succeed, if not a short message for logging with e.g. writeWarning and an oops URL to give the user feedback.
  • I'd personally prefer it if developers were required to normalize their inputs to separate web and topic variables, rather than allowing them to pass things like ("", "Main.WhateverTopic") instead of ("Main", "WhateverTopic"). If we haven't got a function in FuncDotPm for doing this, we ought to publish the internal one there so that this becomes practical.

-- WalterMundt - 04 Mar 2004

Ok. So an adjustment to the implementation is required. Do we agree in principle that the functionality need exist?

-- MartinCleaver - 04 Mar 2004

Well, I have my reservations about the need for it, but Sven agrees that it belongs and I don't care enough to overrule him. Personally, I think that the current read->modify->save cycle is fine for this purpose, as long as you reread the topic right before you make the change, every time. I don't see that as much of a burden; perhaps you do.

Specifically, I don't understand how this solves this issue in a way that is not currently available:

If the appendTopicText function that I wrote on FuncDotPm was implemented, it would not be necessary to "Remember to refresh before you comment" and "a plugin to accept input from e-mail" would be easier.

Quite simply, plugins already have topic read and topic save. If CommentPlugin doesn't read the topic when it appends, but instead relies on the (possibly outdated) content submitted by the client, that doesn't mean it can't be done.

-- WalterMundt - 05 Mar 2004

The CommentPlugin does read the topic immediately before the save. However the function proposed here would be useless, because the CommentPlugin interleaves comments with the text. Comments may be inserted before, after, or anywhere within the text. The reason it needs the refresh comment is that the topic may be locked for an extended edit by another user. The beforeSaveHandler used by the CommentPlugin offers no documented way to raise an exception to the save process, so it can't refuse to save if the topic is locked.

-- CrawfordCurrie - 05 Mar 2004

CC: The beforeSaveHandler used by the CommentPlugin offers no documented way to raise an exception to the save process, so it can't refuse to save if the topic is locked.

Another reason to use the commonTagsHandler (called by viewauth) instead of the beforeSaveHandler. See my comment, 04 Mar 2004, in CommentPluginDev.

-- PeterThoeny - 10 Mar 2004


(15:14:12) maphew: how is the new TWikiIRC interwiki rule used? I want to link to about ten minutes ago.
(15:18:14) WillNorris: i think you have to find the entry in colas' logs
(15:18:38) WillNorris: and click on the time and get a url for that link
(15:18:47) WillNorris: and then strip off the TWikiIRC-provided part
(15:19:14) maphew: oh, labour intensive then. oh well.
(15:19:22) MartinCleaver: I was thinking about this about 10 mins agp
(15:19:34) MartinCleaver: I concluded that LOGGER should interject every 10 mins
(15:19:43) MartinCleaver: with the URL to paste
(15:20:08) MartinCleaver: or that this could be built into the IRC client (harder)
(15:20:12) maphew: no, too much interjection already. we should be able to ask logger as needed
(15:20:28) MartinCleaver: or that we ask logger to appendToTopic betweem markers
(15:20:47) MartinCleaver: i.e. LOGGER start TWikiCssNames
(15:20:53) MartinCleaver: LOGGER stop TWikiCssNames
(15:21:11) MartinCleaver: at which point it takes the buffer and slaps it through TWikiFunc::appendToTopic
(15:23:04) maphew: the current method (go to log, load html page, find time, copy url) negates the usefulness of using interwiki. It's actually one more step (deleting the irrelevant part of the url rather than simply pasting)
(15:23:16) WillNorris: maphew: correct
(15:23:39) WillNorris: MartinCleaver: too bad you usually don't know you want to start a marker to a conversation when it begins and ends
(15:24:28) MartinCleaver: perhaps you just need to be able to ask for the current URL then

-- MartinCleaver - 17 May 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff AppendTextToFunc.diff r1 manage 2.9 K 2003-10-06 - 00:03 MartinCleaver Work in progress
Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2006-04-06 - MeredithLesly
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.