Feedback on ControlsPlugin

-- ThomasWeigert - 20 Feb 2005

Thomas, thank you for contributing this useful utility.

How about publishing the PluginBenchmarks?

-- PeterThoeny - 20 Feb 2005

Added a flag to generate an option in select to be populated by a passed in URL parameter, as widely used (e.g., TWikiInstallation).

This got me to thinking that I could probably generate the whole form-based search as in TWikiInstallation automagically:

• Present the user with the list of form fields
• User selects the input mode (text, select) for filter fields
• User selects the fields for output
• User selects regular expression to limit the topic

-- ThomasWeigert - 21 Feb 2005

I'm just stuck with the user interface... it is easy to see how one can write a form that generates the whole search (plus the table formatting around it).

I guess the mode would be this:

1. tag %GENERATE_QUERY{form="..." topic="..."} expands into a form with all the selections to be filled in
2. on submit that kicks of an non-inline search rendering the table with the filters.
3. now the user can play with the filters....

What I am envisioning is that a user can decide what fields they are interested in, apply the filter, and dump the relevant part of the data base to the screen.

-- ThomasWeigert - 21 Feb 2005

I added a new plugin that does what I describe above... see GenerateSearchPlugin.

-- ThomasWeigert - 25 Feb 2005

How do these two Plugins depend on each other?

-- FranzJosefSilli - 25 Feb 2005

They don't. They solve a related problem but are independent. The GenerateSearchPlugin is the much more broader solution, but the ControlsPlugin helps if you want to create custom forms.

-- ThomasWeigert - 25 Feb 2005

This looks like a great plugin, however it has a certain ironic aspect for me. A long time frustration for me has been I have to manually define options for TWikiForms due to the lack DynamicFormOptionDefinitions. I regularly define dynamic options for html forms (using FormattedSearch). So this plugin offers option instead to reference a set of options that I have to define manually. What would even more convienent would be able to define dynamic options in both html and TWikiForms.

-- LynnwoodBrown - 04 Mar 2005

Lynnwood, I am not quite sure what you are looking for, so if you could spec it out a little more, I could take a look. However, if you are thinking of generating options to a form from a search, I have this implemented already. Please look at FormsAddOn (look in section "Definition of possible field values through searches").

-- ThomasWeigert - 05 Mar 2005

Opps - once again caught not keeping up with the amazing current rate of TWiki-innovation! Thomas - indeed you've provided in FormsAddOn exactly the feature I've been wanting - plus several other useful enhancements. Thank you so much! (PS - I've noted in DynamicFormOptionDefinitions the availablility of this solution.)

Beyond that, my aplogies for the vaguely worded gripe above - particularly in light of the rate and quality of your contributions recently. I am excited by your renewed involvement in TWiki's development and the directions you seem to be taking it. I'll will work on being more concise and rigorous in submitting my feature/enhancement requests. Thanks again.

-- LynnwoodBrown - 07 Mar 2005

checked .zip into CVS

-- WillNorris - 27 Jun 2005

The example in the plugin homepage describes how to create the control. But how do you use the result of the control ?

-- AviYagodnick - 27 Sep 2005

You use it whereever you would use an HTML control; this control is generated automatically. There are many TWikiApplications which you can use as a sample...

-- ThomasWeigert - 27 Sep 2005

Ported to Dakar.

-- ThomasWeigert - 08 Jul 2006

Added the ability to define hierarchical menus, where the options available in dependent menus are determined by the selection made in an earlier menu.

Added the abilty to select a subset of a menu based on a selection in, say a URL parameter.

-- ThomasWeigert - 18 Jul 2006

Thanks Thomas for your continued support for the latest TWiki 4 release!

-- PeterThoeny - 18 Jul 2006

Another small enhancement to the usability of the dependent select feature was added...

-- ThomasWeigert - 19 Jul 2006

Would it be possible to set include sections for the field value definitions, so all definitions can be on one page?

-- ArthurClemens - 19 Jul 2006

Arthur, can you please describe your spec in more detail? By the way, thanks for the great suggestion on how to generate the onLoad events.

-- ThomasWeigert - 19 Jul 2006

As ThomasWeigert mentioned in HtmlFormsPluginDev, I think it would be helpful to join efforts and merge the features of the new HtmlFormsPlugin into the existing ControlsPlugin. Both plugins have overlapping features.

-- PeterThoeny - 13 Sep 2006

I seem to have a problem with this plugin.

Sample code:

<form name="newreport" action="%SCRIPTURLPATH%/edit/%WEB%/">
| *Subject*  | <input type="text" name="Subject" size="80" value="" />  | give a short description  |
| *Exchange*  | %CONTROL{"Exchange" form="newreport" topic="SupportedCountries" type="select" size="1"}%  |  |

  <input type="hidden" name="topic" value="InterventionTask200610191634" />
  <input type="hidden" name="templatetopic" value="InterventionTemplate" />
  <input type="hidden" name="topicparent" value="%BASETOPIC%" />
  <input type="submit" value=" Create report " />
</form> 

The actual list in SupportedCountries renders to a 3-level selection.

After correctly selecting the items i get in the QUERY_STRING sent:

 ... Exchange0=level1&Exchange2=level3&Exchange3=level3 ...

Item Exchange2 gets the value of the third level again instead of the level2 value.

So the resulting template is filled with the wrong value for the *Exchange2" field.

Even with your example (CitiesMenu) in the *.zip file i get in the QUERY_STING:

line0=Argentina&line1=CitySections

The second level (line1) is wrong. I've selected "Corral the Bustos".

Hope that helps tracking down the problem.

I am using Controls plugin dd. 06 Aug 2006 - 12:16.

-- PetricFrank - 20 Oct 2006

It seems i tracked it down. The problem is not in the Javascript code - it is the plugin code.

At the end of the function ControlsPlugin::getHierarchialMenu looks like this:

        if ( $subtopic && TWiki::Func::topicExists( $web, $subtopic ) ) {
          # hierarchical control
          getHierarchicalMenu( $session, $web, $subtopic, $name, $type, $size, $sep, $url, $level + 1, $ite
m, $msg1, $msg2 );
        }

        $val .= "   <option value=\"$subtopic\">$item</option>";
        $idx++;
      }

      $menuStack[$level] .= $val;
}

should look like:

        $val .= "   <option value=\"$item\">$item</option>";

I don't know whether this is the correct fix or not. I hope the someone with more knowledge on TWiki have a look on this to confirm (or not) its correctness.

-- PetricFrank - 23 Oct 2006

Petric thanks for your suggestion. I will check tomorrow.

There is a bigger problem with the JS though, I believe. I have not figured out how to send the current value of URL parameters into the JS code. Thus, if you, for example in a search, have selected a value of an option and re-render the topic, that value is not reflected in the choice list, when hierarchical menus are used. When non-hierarchical menus are used, that works fine, of course.

If you understand JS, that would be a wonderful thing if you could check whether that is fixable. This JS code is the only one so far that I found which has a graceful fallback when a user disables JS or when JS is not allowed by a system administrator. So I would prefer to stick with this than moving to another JS menu code...

-- ThomasWeigert - 23 Oct 2006

Sorry, i have rather limited JS knowledge. My Java knowledge is better ...

I guess you may extend the initialize routine DepSelectOne in the code:

<!--Exchangenewreport--><SCRIPT type="text/javascript">
//<![CDATA[
   addLoadEvent(initControlExchangenewreport);
   function initControlExchangenewreport () {
      new DepSelectOne(document.newreport.elements['Exchange0'], 'Exchange1', 'Exchange2');
   }
//]]> 

with an additional parameter (or more) to get the values. Due you generate the code above inside your plugin this may work.

I've used the JS debugger which is part of Mozilla to get an idea what the JS code is doing. After realizing that the wrong selection comes from the generated HTML code (<option> tags) i switched to the plugin code to fix the issue.

An other thing found is that you can not define non wiki-words with dots in between (like 1.2.3) or escaped wiki-words (like !Web.GotMe) as option values.

-- PetricFrank - 24 Oct 2006

Idea: Add an option to limit the depth the options tree is traversed.

For example: if the topic parameter refers to an definition which would result in 5 drop down boxes, but for the current form you need only the first three ...

So - what about %CONTROL{ ... maxdepth="3" ... }% ?

-- PetricFrank - 16 Nov 2006

Can I add a couple of feature requests?

• Let the control input accept a comma-delimited list of values, similar to HtmlFormsPlugin
• Add a FORM control that accepts an action parameter (or FORMSTART and FORMEND)
• Add support for textfield and textarea

-- ArthurClemens - 03 May 2007

Where do I find info about how to upgrade this plugin to TWiki 4.2? I get errors installing, "Cant locate object method findUser via package TWiki::Users.

-- LarsEik - 03 Apr 2008

Check the offical TWikiFuncDotPm, those functions should survive TWiki updates. If you can't find a suitable function consider using conditional code so that the plugin runs on more than one TWiki version. See some (outdated) hints in HandlingCairoDakarPluginDifferences.

-- PeterThoeny - 05 Apr 2008

I'm trying to use this on my TWiki 4.2 site and when I try and view the CitiesMenu example topic I get:

TWiki detected an internal error - please check your TWiki logs and webserver logs for more information.

Undefined subroutine &TWiki::Form::_getPossibleFieldValues called

This function is not in the TWikiFuncDotPm list and of course it doesnt exist in the Forms.pm library so basically its a broken plugin and cannot be used with TWiki 4.2.

Here is the error I see in data/warn200806.txt:

| 25 Jun 2008 - 13:32 | Undefined subroutine &TWiki::Form::_getPossibleFieldValues called at C:/websites/twiki/lib/TWiki/Plugins/ControlsPlugin.pm line 156. at C:/websites/twiki/lib/TWiki/Plugins/ControlsPlugin.pm line 156 TWiki::Plugins::ControlsPlugin::getListOfFieldValues('TWiki=HASH(0x16a8960)', 'Sandbox', 'CitiesMenu', 'line', 'select', 1, ' ', 'off', 'Select previous level first', ...) called at C:/websites/twiki/lib/TWiki/Plugins/ControlsPlugin.pm line 93 TWiki::Plugins::ControlsPlugin::handleControls('TWiki=HASH(0x16a8960)', 'TWiki::Attrs=HASH(0x23bb288)', 'CitiesMenu', 'Sandbox', 'TWiki::Meta=HASH(0x1da6ef4)') called at C:/websites/twiki/lib/TWiki/Func.pm line 2232 TWiki::Func::__ANON__('TWiki=HASH(0x16a8960)', 'TWiki::Attrs=HASH(0x23bb288)', 'CitiesMenu', 'Sandbox', 'TWiki::Meta=HASH(0x1da6ef4)') called at C:/websites/twiki/lib/TWiki.pm line 2660 TWiki::_expandTagOnTopicRendering('TWiki=HASH(0x16a8960)', 'CONTROL', '"line" form="test" type="select" size="1"', 'CitiesMenu', 'Sandbox', 'TWiki::Meta=HASH(0x1da6ef4)') called at C:/websites/twiki/lib/TWiki.pm line 2581 TWiki::_processTags('TWiki=HASH(0x16a8960)', '---++ Example\x{a}\x{a}Below is the definition of the hierarchical me...', 'CODE(0x180ca70)', 16, 'CitiesMenu', 'Sandbox', 'TWiki::Meta=HASH(0x1da6ef4)') called at C:/websites/twiki/lib/TWiki.pm line 2505 TWiki::expandAllTags('TWiki=HASH(0x16a8960)', 'SCALAR(0x182254c)', 'CitiesMenu', 'Sandbox', 'TWiki::Meta=HASH(0x1da6ef4)') called at C:/websites/twiki/lib/TWiki.pm line 2857 TWiki::handleCommonTags('TWiki=HASH(0x16a8960)', '---++ Example\x{a}\x{a}Below is the definition of the hierarchical me...', 'Sandbox', 'CitiesMenu', 'TWiki::Meta=HASH(0x1da6ef4)') called at C:/websites/twiki/lib/TWiki/UI/View.pm line 396 TWiki::UI::View::_prepare('---++ Example\x{a}\x{a}Below is the definition of the hierarchical me...', 'TWiki=HASH(0x16a8960)', 'Sandbox', 'CitiesMenu', 'TWiki::Meta=HASH(0x1da6ef4)', 0) called at C:/websites/twiki/lib/TWiki/UI/View.pm line 377 TWiki::UI::View::view('TWiki=HASH(0x16a8960)') called at C:/websites/twiki/lib/TWiki/UI.pm line 159 TWiki::UI::__ANON__() called at C:/websites/twiki/lib/CPAN/lib//Error.pm line 379 eval {...} called at C:/websites/twiki/lib/CPAN/lib//Error.pm line 371 Error::subs::try('CODE(0x236f2c)', 'HASH(0x2099674)') called at C:/websites/twiki/lib/TWiki/UI.pm line 197 TWiki::UI::run('CODE(0x1899114)', 'view', 1) called

-- JamesGMoore - 25 Jun 2008

If the subroutine _getPossibleFieldValues is copied from an old Form.pm (say from TWiki 4.1.2) & added to ControlPlugin.pm then it works again.

Why the "minor" upgrade from 4.1.2 to 4.2 completely rewrote Form.pm is beyond me.

-- ChrisHogan - 26 Jun 2008

Several new functionalities where delivered on 4.2, and some improvement to the way Forms are handled. These changes where backward compatible, thus the minor release.

Only the public API (what is in Func.pm) is guaranteed to work between releases, thus plugins cannot rely on any internal core function or they have the risk of being broken on the next release.

I think that you should raise the request in Codev to publish the function you need, so it is available in a future release, because given the current discussion to change the storage of metadata having a function in the public API will shield you from that change if it ever happens.

-- RafaelAlvarez - 27 Jun 2008

I spoke too soon. restoring the _getPossibleFieldValues restores most of the capability of this plugin, but not the cascading menu. If you have a simple two level, both items get created and populated. the cascade_select.js is included, but but I can't for the live of me see how the javascript is linked to the select items.

-- ChrisHogan - 27 Aug 2008

It would seem that the addLoadEvent javascript function has vanished? If I manually insert one it starts working properly.

-- ChrisHogan - 27 Aug 2008