Item10902: Configure should show expanded values for parameters

Priority: Enhancement
Current State: Closed
Released In: 1.1.4
Target Release: patch
Applies To: Engine
Component: Configure
Branches:
Reported By: GeorgeClark
Waiting For: GeorgeClark
Last Change By: GeorgeClark
From Item10873

Configure should show the expanded results of variables that reference other variables using embedded $Foswiki::Cfg{key}

  • default field values aren't being expanded. One I'm looking at right now is {Htpasswd}{FileName}, which shows $Foswiki::cfg{DataDir}/.htpasswd ... correct. Configure shows the exact contents of the fields, and not how they will be interpreted. Otherwise (with the current design) the first save would convert the indirect references to absolute.

-- GeorgeClark

  • _default field values aren't being expanded. Otherwise (with the current design) the first save would convert the indirect references to absolute. Then the field should show {itemname}, not "$Foswiki::cfg"... That's programmer crypto-speak finding its way into an otherwise elegant GUI.

Agree that expanding into a note would be positive - >>I<< don't know what these variables will expand to without clicking around.

-- TimotheLitt

  • Default ($computed) values aren't user friendly (show the expanded value somehow). This is actionable, but I don't think it should block 1.1.4 right now (at least, we have more urgent bugfixes we want people to get).

-- PaulHarvey

Creating a Checker.pm function showExpandedValue Any checker can include a note with the expanded value by including my $msg = $this->showExpandedValue($theField)

-- GeorgeClark - 19 Jun 2011

Sounds good. Shouldn't this be the default? E.g. if the UI is displaying a value box that contains 'Foswiki::', can't it call show ExpandedValue automagically?

Otherwise, every checker will have to be updated - and fields without checkers would grow them. (Related note: I have code that allows for a default checker for each Type - that would simplify things, as we could have StringChecker, BooleanChecker, etc. Coming when I can port TFW to Foswiki...) But I suspect the UI is the better place for doing showExpandedValue.

Come to think of it, default checker is pretty independent - here's the diff from TWiki's trunk:

Index: core/lib/TWiki/Configure/UI.pm
===================================================================
--- core/lib/TWiki/Configure/UI.pm      (revision 21511)
+++ core/lib/TWiki/Configure/UI.pm      (working copy)
@@ -30,6 +30,7 @@
 package TWiki::Configure::UI;

 use strict;
+use Carp;
 use File::Spec;
 use FindBin;

@@ -93,7 +94,8 @@
 # Static checker factory
 # Checkers *need not* exist
 sub loadChecker {
-    my ($id, $item) = @_;
+    my ($keys, $item) = @_;
+    my $id = $keys;
     $id =~ s/}{/::/g;
     $id =~ s/[}{]//g;
     $id =~ s/'//g;
@@ -103,8 +105,16 @@

     eval "use $checkClass; \$checker = new $checkClass(\$item);";
     # Can't locate errors are OK
-    die $@ if ($@ && $@ !~ /Can't locate /);
-
+    if ($@) {
+       die $@ unless ($@ =~ /Can't locate /);
+       # See if type can generate a generic checker
+       if ($item->can('getType' )) {
+           my $type = $item->getType();
+           if ($type && $type->can('makeChecker')) {
+               $checker = $type->makeChecker($item, $keys);
+           }
+       }
+    }
     return $checker;
 }

Used in generic Types (in this case, SCHEDULE) as:
sub makeChecker {
    my $class = shift;
#    my( $item, $keys ) = @_;

    # Return a generic checker, which works for us
    # because no item(key)-specific information is required.
    my $checker = TWiki::Configure::ScheduleChecker->new( @_ );
    return $checker;
}
-- TimotheLitt - 28 Jun 2011
 

ItemTemplate edit

Summary Configure should show expanded values for parameters
ReportedBy GeorgeClark
Codebase 1.1.3, trunk
SVN Range
AppliesTo Engine
Component Configure
Priority Enhancement
CurrentState Closed
WaitingFor GeorgeClark
Checkins distro:810665813be3 distro:e3f1200f0c45 distro:e8b277ac7c1c
TargetRelease patch
ReleasedIn 1.1.4
Topic revision: r8 - 17 Dec 2011, GeorgeClark
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License