create new tag
, view all tags

FeedbackPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on FeedbackPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

FeedbackPlugin V1.29 based Development and Discussions

This is really getting into shape. Except that the j-script stuff is not working on IE5.5. Dunno if it works on mozilla - all I get is "error on page" in the status bar at the bottom of the IE-Window. IE says, there is an invalid argument in line 48, character 8

newwindow=window.open("about:blank","Enter Comment","titlebar=0,width=400,height=300,resizable,scrollbars");


What I really would like to see is a replacement of the buttons by a small icon at the side of a paragraph.

-- MatthiasWientapper - 19 Sep 2002

I am a bit clueless on the IE aspect, it works on Mozilla 1.0.? . Wout are you still listening - can you help out?

-- FrankHartmann - 19 Sep 2002

FeedbackPlugin V1.19 based Development and Discussions

Many thanks for the good ideas and excellent feedback for the 1.16 release. I decided to make the next releases in small steps, so not everythink is implemented already. Please look at the roadmap and the known issues section on FeedbackPlugin.

Some notes to the changes of 1.19:

  • with respect to the security of user entered perl regular expressions there is no progress. I reread perlsec and there was no eye opener for me. In the V1.16 release I filtered out some special characters, but now I no longer do this.
  • I found the twiki plugins form api. I am curious if I used the funcions as they were intended to be used.

generally v1.19 is a proof of concept release. It looks somewhat clumsy. Have fun.

-- FrankHartmann - 25 Aug 2002

FeedbackPlugin V1.16 based Development and Discussions

Some thoughts

I haven't been able to try the plugin yet, but reading the code and writing down what I'm thinking:

  • If I read the code correctly, the idea is that people choose text they want to comment on, create a row in the feedback topic with a regular expression, and add their comment? The FeedbackPlugin text is not very clear about that.
    • Usually I mark the part out of the text where I want my comment to appear, then cut and paste it to the table. Regular Expressions are possible, but not needed. To add a comment after read the code correctly, you would have to specify |code correctly|Main.FrankHartmann|Thank you for the review!| - FrankHartmann - 20 Aug 2002
      • Ok, so then the automatic linking could just use the last few words of a paragraph. -- WoutMertens

  • It would be useful to make the default feedback topic not be DefaultFeedbackTopic, but %TOPIC%Feedback instead. I think.
    • Very good idea, will do this! - FrankHartmann - 20 Aug 2002
    • Or do you think people will want to comment on something any time a regular expression matches in any topic?
    • In that case, I think it would be useful to be able to have multiple %FEEDBACK% tags, or a web-wide feedback topic.

  • There is a hard coded url in there: http://mattzz.dyndns.org/twiki/bin/view/Plugins/FeedbackPlugin . Shouldn't that be twiki:Plugins/FeedbackPlugin instead?
    • This was up to now the homepage of the plugin. I thought, that I wait until CVS for plugins is ready, but this seems to be a long story. I will change this next release, it is not needed for functionality - FrankHartmann - 20 Aug 2002

  • As far as I can tell, the feedback is being parsed, even if feedback display is off.

This seems like a useful plugin, except the data entry is a bit difficult. Maybe there could be a way to mark each paragraph with an anchor name and then use Javascript to get the anchor name and allow you to add a comment to that paragraph. I don't know if that is possible though, just thinking out loud (Actually, I would love a feature like that...)

...After some thought: I think all you have to do is add an onDoubleClick handler for each paragraph. I don't know if that is possible, but then you could give the handler the number of the paragraph, and it could open a little form that lets you add a comment to the feedback topic. The plugin can then add the comment to the end of that paragraph.

And for browsers that have decent css2 support (Mozilla) you could even do it without Javascript: See SandBox32 for an example.

  • The SandBox32 example page is broken - there are no css instructions there. And while I can view the intended effect by going back to revision 1.3 only the results are available, not the code which generated it. -- MattWilkie - 19 Sep 2002

Matt, please see: http://twiki.org/cgi-bin/view/Sandbox/SandBox32?rev=1.3&raw=on here is the code for reference again:

this is a test (hover over me, only works for mozilla and other css2 browsers): [imaginary comment-this-paragraph link]

<!-- <pre> -->
P.edit span { display: none }
P.edit:hover span { display: inline }
<!-- </pre> -->

<p class="edit">this is a test (hover over me, only works for mozilla and other css2 browsers): <span>[imaginary comment-this-paragraph link]</span>

rdiff really helps to find the last changes! If they are in the middle of somewhere

-- FrankHartmann - 19 Sep 2002

The only problem remaining is how to identify the paragraph. If you just keep the number, it will mess up the comments if someone adds a paragraph in the middle of the text. And automatically making a regular expression that uniquely identifies the paragraph is probably not that easy.

-- WoutMertens - 20 Aug 2002

I use lynx quite often, so anything which relies on javascript for basic operation is not acceptable. However I really would like adding something like this SandBox32 thing as an additional way to show the comments!

I am not up to date with respect to html alike standards. Which browsers support css2?

  • Browsers which support css2 well are: Mozilla 1+ (Netscape 6+), Opera 5+, Internet Explorer 5.5+. I'm not sure about the current state of non-gui browsers (lynx, jaws, etc.) The guys at css-discuss-list would know. -- MattWilkie - 19 Sep 2002

You said, that in your opinion the data entry seems a bit complex. I have to agree here. My plan was to create something based on TWiki forms, but I did not specify this up to now. Currently adding very long comments is not very easy.

-- FrankHartmann - 20 Aug 2002

The only browser I know that allows that trick is Mozilla. But more should follow...

Furthermore, by using the last few words of a paragraph, a Javascript function could be made for very easily adding a comment. But it wouldn't be required. With a form like on the CommentPlugin, you can cut'n'paste context yourself and add a comment normally easily.

And if we automate the comment adding, we could add a timestamp automatically, which would be useful IMHO.

Another idea: Show all the comments that didn't match at the bottom, as orphaned comments with 'delete' buttons. (possibly with checkboxes so you can delete more than one at the same time)

And I made a javascript thing that shows doubleclicking of paragraphs: SandBox42. No forms and stuff yet, I don't know any Javascript. Obviously wink

-- WoutMertens - 21 Aug 2002

I'm sorry that I can't comment on the more technical aspects of your implementation, but I would like to say that I very much like your approach that allows adding a comment about a specific paragraph within a web page without having to make any change to that page. This allows commenting on non-wiki pages - in fact, any web page. This is exactly the functionality I am looking for as part of TWikiAsWebCommentaryTool. I can see why this approach provides some challenges but I for one think it would be worth the effort.

-- LynnwoodBrown - 21 Aug 2002

Lynwood, currently the plugin works somehow reverse to your expectations. The 'owner' of the page which shall be commented has to enable this feature by adding a %FEEDBACK% tag to his page.

The FeedbackPlugin then combines the page of the 'owner' and the table (from another page) where the comments are in and displays them combined.

So the restrictions are currently, that it has to be a TWiki page, which shall be commented and the 'owner' of the page has to enable the FeedbackPlugin. I use it for my TWiki Weblog, where I do not want others editing it, but still be able to comment.

Thinking now in the other direction it would not have been difficult to operate in reverse. Having a 'Feedback page' pull in an external Web page (similar to %INCLUDE%) and combine them with comments. Somehow there would be much more HTML markup in as I now only read the raw TWiki format.

Wout, I played with SandBox42 and I am quite pleased! I have to admit that I have no idea what you do there, but this is a very convenient way entering comments. It would be nice understanding where the data I entered went to, or what is needed to get it into a plugin!

It would limit yourself as far as I can see to something operating on paragraphs but this is ok for me.

So it seems somehow, that I could do something like the following:

The Plugin should now handle three Pages:

  1. A (external) webpage, which shall be commented
  2. A TWiki page holding the comments
  3. A TWiki page controlling the rendering.

The Plugin (triggered by an access of the rendering page) could now read in the (external) webpage, split it into paragraphs, wrap some javascript/html around it and display it with comments on or off .

By double clicking on a paragraph a comment will be created and added to the TWiki page holding the comments. It still has to be possible to add comments with javascript disabled, but this should be doable.

-- FrankHartmann - 21 Aug 2002


  • Doing this for an external webpage would mean filtering that external page through TWiki. Don't know if that is a very good idea. It would mean different code than internal pages, because you don't have the TWiki text, but only html source.
  • If you want to see how I do the Javascript thingie, just look at the raw text. It's actually quite simple... Currently, nothing is being done with the data it collects, though...

More ideas:

  • Always allow the feedback, unless there is a %NOFEEDBACK% tag in the text. Comments are always stored in %TOPIC%Feedback pages, and are automatically shown. If there is no %TOPIC%Feedback page, just make adding comments possible. The idea is that the normal comments like these will normally be done with the FeedbackPlugin.
  • Put comments without a regular expression at the end of the topic, under a "Comments" heading.
  • Put comments with a regular expression that doesn't apply any more under a "Orphaned comments" heading, with delete links.
  • Give your own comments an Edit link, that allows you to change the comment text. This assumes that you have the SessionPlugin or authenticated viewing of course...
  • Give the comments a number. If the regular expression is of the form: "Parent: [0-9]+", treat it as a reply on the comment with that number. Render it under the comment and indented.
  • Change the WebChanges rendering so that changes to the %TOPIC%Feedback topic will show as "%TOPIC% got a comment, these are the first few lines: ..."
  • Use css to quickly turn the comments off for browsers that support it (you need javascript as well). Otherwise, you have to re-render the page like it is now.
  • Allow viewing only top-level comments, only the comments since the last revision, only comments from a certain author, ...
  • Allow editing a page with all comments in the source. This is so you can refactor a topic easily.
  • Allow mailing in a reply on a topic change, and that reply will be added as a comment. But topic change notifications would have to be changed to show the nature of the change then. (I would really like that)
  • Allow a user to choose to have comment and reply links on all paragraphs (for lynx users)

This is how I think it should work:

  • Always show the on/off/add control, except when the %NOFEEDBACK% tag is present
    • This should probably be part of the skin
  • Clicking on/off will turn the comments on and off with css if possible, otherwise the page gets redrawn.

    • This is easy to do, just ask me to do it when the plugin is ready for it.
  • Clicking Add, or double-clicking a paragraph, will open a new window with a form that allows you to set the regular expression. This form allows you to set the regular expression, and the comment. If you double-clicked, the regular expression is pre-filled for you. When you submit, the comment is added with a timestamp, just like the PollPlugin does.
    • For doing it on paragraphs, you need to change each <P> tag after all the TWiki rendering has been done. This can be done by the plugin. And the plugin can save the last 5 words of the twiki paragraph source as the id of the paragraph, so the javascript has the correct regular expression. I think.
    • Put the regular expression somewhere so people can immediately add a comment without having to think about it. People with modern browsers will never have to worry about it.
  • Comments with empty regular expressions are put at the bottom in chronological order, with their child comments of course.
  • All comments have a hidden reply link, so that browsers without css (and presumably without javascript) can easily reply to a comment. Or we could make it so that the reply link is hidden by Javascript, which is more direct.

-- WoutMertens - 22 Aug 2002

Two pieces of feedback...

  • I would recommend to use this plugin jointly with EditTablePlugin. It is much nicer for the user to enter the comments in a prearranged table.
  • What would be even better would be to make this plugin work with SimpleTableEntryUsingForms. That enhancement to tables seems ideal for this type of application: you present the user with a form to fill out, which is much more intuitive than typing in a table. (I defined a form that uses textarea for the feedback to be provided which is even nicer than the text box that is provided by EditTablePlugin.) Unfortunately, SimpleTableEntryUsingForms stores the table in metadata rather than inline and these tables are, therefore, not recognized by this plugin.
  • Albeit the description makes mention of regular expression, using regular expressions as the search text does not seem to work for me.

-- ThomasWeigert - 22 Aug 2002

Thomas, did you take a look at SandBox42? It does what you ask, and I don't think it will be too difficult to implement.

I realize that there is potential for EditTablePlugin, SimpleTableEntryUsingForms, PollPlugin and this plugin to work together. They all have a need for:

  • Allowing a user to enter data in a user friendly way
  • Allowing an editor to define entry forms/display forms in a user friendly way
  • Storing the data in a correct manner (locking, handling any type of data, retrieving, deleting just that item, and so on)

This needs discussion about how to do it. I think this warrants a new topic: DataHandling

But in the mean time, I think we should just do all changes that we want (Without doing too much work on the data handling side). It will take a while for other methods to be available.

-- WoutMertens - 22 Aug 2002

I am a bit overhelmed by the amount of feedback an excellent ideas. I am currently trying to synthesize these to the structure (dataflow) of a better FeedbackPlugin. This is still difficult for me: while some technical details are clear other things remain vague.

The most unclear things for me are:

  • How to enable a convenient way of entering data? This is the same as DataHandling
    • Thomas pointed out EditTablePlugin, SimpleTableEntryUsingForms
    • Wout presented Sandbox.Sandbox42
    • additionally I read the text to DatabasePlugin which has appearently the same Problem and yet another solution, which uses some external PHP code for editing tables as far as I can see.
  • How do I merge my convenient ways of entering data?
    • I want both: with and without Javascript.
    • I think that the way I outlined above should work for entering data. Just use a form that will be added to a table, and use the Javascript trick to populate the table and pop up the form. If you don't have Javascript, just click on the Add link, that will open the form without the regular expression filled in. -- WoutMertens

some technically details, which are unclear:

  • in the SandBox42 Javascript Code:
    • can the id in
      p id="1" ondblclick="cmt(this)" 
      be a string?. I guess I use this id to later identify to which paragraph my comment belongs. Right? I thought to do some hash (like md5) on the paragraph to indentify them uniquely instead of using regexps.
      • According to http://www.w3.org/TR/html4/types.html#type-name, 'ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").'
      • If you use a hash on a paragraph, it will only work if the paragraph is not changed. I was thinking about using a paragraph number, but that means that anytime a paragraph is added or deleted, all the comments are at the incorrect place.
      • I'm beginning to think that it would be better to just add comment markers in the text, like %COMMENT{"3"}%. That way, the place of the comment is saved in the topic, but the text is in the other topic. The disadvantage is of course that you have to change the commented topic...
    • Is there an upper limit of how many javascript wrapped paragraphs a browser can handle? I am badly burned by a quake2 level of our office, where I wanted destructable walls. The quake engine did not support many of them and was unable to trace which one I hit with my rocket, so it went through them.
      • I guess this depends on the browser. Only one way to find out... Make a page with a thousand paragraphs, and see if it still works. smile There certainly is no limit defined in the HTML specifications.
    • Forgive my ignorance: After I press the Submit button, where is my form data? I did not find a TWiki Plugin API which would give it back to me. If I understand you right I will need to provide a cgi script like the bin/poll from the PollPlugin. Is this correct or can I proceed without such a thing?
      • This was just a quick and dirty setup. Normally, you set up an action that tells the browser where to place the form data, but I just left it empty. There currently is no API for form data. I guess that SimpleTableEntryUsingForms would be the way to go.

With respect to Thomas remark on non working regular expressions: Regular expressions are crippled currently intentionally. Basically currently it uses something like a substring search. The reason for this is that I found in the Perl Cookbook section 6.11 an example of a user supplied regexps which made me nervous as I did not understand it fully and it did not work for me. Maybe it will need the correct pattern delimeter to work? :

$pat = "You lose @{[ system('rm -rf /tmp/*')]} big here";

I was not aware that such things are possible and would welcome feedback on this.

  • Well, try reading the perlsec manpage for more information about this topic. In short, if you are careful, you can use user provided data in your program, and with taint mode (switched on for all TWiki binaries), Perl really helps you in this respect.

Further I would welcome a hint why the %FEEDBACK% tag is expanded partly even within verbatim tags.

  • Take a look at TWiki::takeOutVerbatim() and TWiki::putBackVerbatim(). These functions will allow you to do global replacements the way you do without doing it inside verbatim tags. I think.
  • Another way is to put your replacement in commonTagsHandler(), where it should be. Then TWiki will take care of the verbatim stuff. I think.

-- FrankHartmann - 23 Aug 2002

I put my comments to the above comment inline

-- WoutMertens - 25 Aug 2002

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2006-09-20 - PeterThoeny
  • 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.