Tags:
create new tag
, view all tags

FormFieldsPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on FormFieldsPlugin 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

FormFieldsPlugin development

Still very early days for this plugin. I'd appreciate feedback, since I'm happy with some aspects but not happy with others e.g. the colour chooser.

See ExtendingFormControls

-- JohnTalintyre - 04 Jun 2003

Should you have written ALLOWTOPICRENAME - is ALLOWWEBRENAME not for renaming a web?

Is there a demo anywhere?

-- MartinCleaver - 08 Aug 2003

ALLOWWEBRENAME is correct see TWikiAccessControl#Deny_Renaming_by_Web.

There is no demo on the internet. Just grab TWiki from CVS or recent beta and add this plugin, trying example from FormFieldsPlugin.

-- JohnTalintyre - 12 Sep 2003

The name of the Plugin is rather misleading. Under a FormFieldsPlugin I would expect a plugin which handles formfields like PeterMasiar developed in CommentPluginIdeas. In future the implementation will go far beyond the comment function, as it can handle different formfields.

An appropriate name would be FormControlPlugin or something similar.

-- AndreUlrich - 26 Sep 2003

-bash-2.05b$ unzip patches/FormFieldsPlugin.zip
Archive:  patches/FormFieldsPlugin.zip
   creating: FormFieldsPlugin/data/
   creating: FormFieldsPlugin/data/TWiki/
  inflating: FormFieldsPlugin/data/TWiki/FormFieldsPlugin.txt
   creating: FormFieldsPlugin/lib/
   creating: FormFieldsPlugin/lib/TWiki/
   creating: FormFieldsPlugin/lib/TWiki/Plugins/
  inflating: FormFieldsPlugin/lib/TWiki/Plugins/FormFieldsPlugin.pm
   creating: FormFieldsPlugin/templates/
  inflating: FormFieldsPlugin/templates/formfields.tmpl

As much as it might be a better idea to include a top level directory in the archive (in this case "FormFieldsPlugin"), it is not consistent with the way most other plugins are packaged.

This will be a pain when it comes to automating plugin installs

-- MartinCleaver - 11 Oct 2003

I failed to install this at http://testwiki.mrjc.com/twiki/bin/view/FormFieldsPluginTest/WebHome

In addition to the instructions, I:

  1. Created WebPreferencesForm from the content of the FormFieldsPlugin on TWikiDotOrg (the bundled version has no demo)
  2. Added WebPreferencesForm to WebPreferences:
  3. Created a
http://testwiki.mrjc.com/twiki/bin/view/FormFieldsPluginTest/FormFieldsPluginTest
  1. Changed the form type of FormFieldsPluginTest to WebPreferencesForm

Now what?

I'm glad I have a testwiki to try things on - I venture most people can't try things without putting them in a live environment.

-- MartinCleaver - 11 Oct 2003

Certainly good practice to have a test environment. Thanks for pointing out some issues with this plugin. When it's in place some extra form controls are possible, the example for WebPreferences should mean easier selection of users and group and a colour chooser (not very good).

I'm hoping other (with better JavaScript than me) will introduce other controls, based on the relatively recent Plugin API changes that allow this.

-- JohnTalintyre - 11 Oct 2003

I've broken this plugin for current code because it makes use of some Javascript-insertion functionality JohnTalintyre introduced, that I marked as unused because it wasn't in Func and wasn't called anywhere in the core code. I guess we'll need to either revert those changes or reintroduce the functionality in a cleaner manner.

-- WalterMundt - 04 May 2004

The EditTablePlugin adds JavaScript in a portable manner to the header:

    if( $_[0] =~ m/^[<][!]DOCTYPE/ && $additionalConditionIfNeeded ) {
        $_[0] =~ s/([<]\/head[>])/$myJavaScriptCode\n$1/i;
    }

That way you do not depend on additional core code functionality.

-- PeterThoeny - 07 May 2004

Installing this plugin in Cairo beta gives the following problems:

[Sun Jun  6 17:39:26 2004] view: Found = in conditional, should be == at ../lib/TWiki/Plugins/FormFieldsPlugin.pm line 260.
[Sun Jun  6 17:48:23 2004] view: Found = in conditional, should be == at ../lib/TWiki/Plugins/FormFieldsPlugin.pm line 260.
[Sun Jun  6 17:48:30 2004] edit: Found = in conditional, should be == at ../lib/TWiki/Plugins/FormFieldsPlugin.pm line 260.
[Sun Jun  6 17:49:16 2004] edit: Found = in conditional, should be == at ../lib/TWiki/Plugins/FormFieldsPlugin.pm line 260.
[Sun Jun  6 17:49:20 2004] preview: Found = in conditional, should be == at ../lib/TWiki/Plugins/FormFieldsPlugin.pm line 260.
[Sun Jun  6 17:49:25 2004] edit: Found = in conditional, should be == at ../lib/TWiki/Plugins/FormFieldsPlugin.pm line 260.
[Sun Jun  6 17:49:28 2004] edit: Undefined subroutine &TWiki::addScript called at ../lib/TWiki/Plugins/FormFieldsPlugin.pm line 270.
[Sun Jun  6 12:49:28 2004] [error] [client 127.0.0.1] malformed header from script. 

Basically:

  • line 260 uses and assignment $multi="twopane" where a comparison was intended
  • the undefined function &TWiki::addScript is called on line 270. This functionality was removed (as indicated above by WalterMundt). It is attached.

-- ThomasWeigert - 06 Jun 2004

PeterThoeny, you pointed to the mechanism of EditTablePlugin to add additional Javascript to the topic. However, there is a short coming in that this requires that the Javascript would have to be added to every topic, whether it is actually needed or not. This is because the plugin does not have access to the text outside of the body only when it executed commonTagsHandler, but at this time we have not yet examined the form fields.

I think it would be good if there were a generic mechanism that allowd Plugins to add Javascript that would then be added in the appropriate place later. E.g., two functions:

  • addScript adds Javascript to be later added to the topic
  • emitScript is called in View.pm or Edit.pm and inserts any Javascript that might have been added in the hidden section of the page.

-- ThomasWeigert - 07 Jun 2004

JohnTalintyre, I'd like to extend this plugin to handle javascript date picker formfields, using the JSCalendarContrib. Would that be in order? Note that because this implies a dependency, I would want to modify it to use the BuildContrib build system.

-- CrawfordCurrie - 08 Sep 2004

.zip file checked into CVSplugins:FormFieldsPlugin

-- WillNorris - 23 Nov 2004

Hi, Thomas' patch is against a pre-Cairo TWiki.pm. Where is the bottom part supposed to go in the new TWiki.pm?

Thanks!

-- JosMaccabiani - 03 Jul 2005

I changed the ModificationPolicy of this extension from ContactAuthorFirst to PleaseFeelFreeToModify due to inactivity. Anyone please feel free to work on this extension.

-- PeterThoeny - 2012-12-03

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2012-12-03 - 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.