Item10001: Implement the features from FlexFormPlugin in MultiTopicSavePlugin.

Use the handleRENDERFOREDIT and handleRENDERFORDISPLAY functions of FlexFormPlugin instead of recreating the core rendering code in this plugin. It's a simple update which I've implemented and am using in production. It means, for example, that the OPTIONS don't need to be defined by pattern matching SEARCHes and custom formfields from other plugins can also be seemlessly included.

There is one possible caveat, however, that comes with select+value type fields. When I implemented this on my system I noticed that only the first select+value field was being properly rendered for edit. From the code in lib/Foswiki/Form/Select.pm this is not at all obvious and perhaps is only a problem on my system, for whatever reason. Anyway, I had to make the following slight change to Select.pm because the options array was being overwritten by the code in the foreach loop of renderForEdit().

100   -    foreach my $option ( @{ $this->getOptions() } ) {
      +    foreach ( @{ $this->getOptions() } ) {
      +       my $option = $_;
101           my %params = ( class => 'foswikiOption', );
102           $params{selected} = 'selected' if $isSelected{$option};
103           if ( defined( $this->{valueMap}{$option} ) ) {
104               $params{value} = $option;
105               $option = $this->{valueMap}{$option};  # without the above change, this line overwrites the array entry in @{$this->{_options}}
106           }

-- DavidPatterson - 11 Nov 2010

Changed the extension to FlexFormPlugin in the bug form.

-- KennethLavrsen - 12 Nov 2010

This enhancement request is on MultiTopicSavePlugin. I have created the following two subs

sub handleRENDERFORDISPLAY {
   my ($session, $params, $theTopic, $theWeb, $topicFQN, $field) = @_;
   $params->{_DEFAULT} = $topicFQN;
   $params->{fields} = $field;
   $params->{format} = '$value';
   my $value = Foswiki::Plugins::FlexFormPlugin::Core::handleRENDERFORDISPLAY($session, $params, $theTopic, $theWeb);
   return _encodeValue($value);
}

sub handleRENDERFOREDIT {
   my ($session, $params, $theTopic, $theWeb, $topicFQN, $field) = @_;
   $params->{_DEFAULT} = $topicFQN;
   $params->{fields} = $field;
   $params->{format} = '$edit';
   my $value = Foswiki::Plugins::FlexFormPlugin::Core::handleRENDERFOREDIT($session, $params, $theTopic, $theWeb);
   $field = Foswiki::Form::fieldTitle2FieldName($field);
   $value =~ s/name="$field"/name="multitopicsavefield{$topicFQN}{$field}"/;
   return _encodeValue($value);
}

and I'm calling them at the appropriate points in _MULTITOPICSAVEINPUT() after doing a

   require Foswiki::Plugins::FlexFormPlugin;
   require Foswiki::Plugins::FlexFormPlugin::Core;
   Foswiki::Plugins::FlexFormPlugin::init($theWeb, $theTopic);

-- DavidPatterson - 12 Nov 2010

Now I understand

I understand the power that this gives, BUT this is violating the principles that a plugin only uses published API.

I do not want MultiTopicSavePlugin to be depending on the exact interface from another plugin that I cannot even protect or control myself. And the other plugin also should not feel bound by keeping a certain interface to internal subs just because another plugin is made as a hack.

I took a quick look and FlexFormPlugin uses methods from the Foswiki session object and these are not defined as API and can change when Foswiki developes. The author of FlexFormPlugin may be very busy with paid work when a new Foswiki release is made available. And we all have to respecy that. The policy of some plugins the way it is enforced prohibits others to fix it. And even if someone is allowed they may also be too busy to act right away. I have seen often that we have had to wait for months before plugins were fixed by various authors. This is not meant as critique of a specific author. Just facts that we all have to take into considerations when we write extensions or even when we just install them and make ourselves depending on them.

My plugins are kept clean API plugins that should always work even you upgrade Foswiki and are not depending on other plugins. That may mean they are less efficient but I prioritize stability and availability. This is also a criteria I use when I choose which plugins I install in production sites.

So I'd rather implement the missing features in MultiTopicSavePlugin. I do have additional plans with this plugin. And I will take the features of FlexFormPlugin into consideration when I enhance the plugin next time.

But I must reject this proposal and I would revert it if checked in. But that does not prevent you from doing what you do in your own installation.

I am changing the headline of this report because I want to remember to consider the feature the hack gives.

I will want to maintain that MultiTopicSavePlugin does not automatically show the formfield the same way as defined in the form. When displaying and editing many topics in a table format you often want the same data represented in a different way. I use this a lot myself.

Example I use a text field with comma separated values instead of checkboxes or multivalue select fields. Or I limit or enhance the allowed values. This is essential for many of the uses I made the plugin for.

-- KennethLavrsen - 14 Nov 2010

Wouldn't it be better to move the FlexFormPlugin capabilities into core than to have a third variant of this functionality in MultiTopicSavePlugin?

-- MartinCleaver - 21 Aug 2011

Commenting is disabled while not logged in