You are here: Foswiki>Tasks Web>Item12204 (08 Oct 2014, GeorgeClark)Edit Attach

Item12204: Configure TABS don't work at level 3+

pencil
Priority: Normal
Current State: No Action Required
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: Configure
Branches:
Reported By: TimotheLitt
Waiting For:
Last Change By: GeorgeClark
I'd appreciate some help with this issue, as I'm sure someone already knows the path thru this maze.

I need nested TAB sections to make the off-line task interface manageable. However, while the code seems to try to support them, they don't work (beyond level 2).

Specifically:
  • Subtab level 3 labels do display
  • The first subtab also displays when the tab is opened.
  • When subtab labels are clicked, the whole right side of the page disappears
  • Description for the subtabs is not displayed.
  • DISPLAY_IF items on the subtab that does display are hidden.

Debugging with a browser shows that the data is present in the HTML, but display:none is set due to configureToggleSection.

It looks to me as though the label hierarchy that the javascript counts on doesn't quite work beyond 2 levels. The javascript also looks suspicious.

I've reduced the real spec file to a short test case. To run it, create the directory in lib/Foswiki/Plugins/TestPlugin, and put the following in a file called Config.spec. Then run configure and select "Menu Test Section" from the left tab.

I haven't investigated level 4 in depth (not sure I need it), but I included it in the test case. If L2 and L3 work, I'd expect 4+ to fall out of the implementation... but it's not a priority.

If you'd like to verify with the real spec (over 200 lines, 5 tabs, one with 4 sub-tabs), I can provide it.

Note that if you remove the second and third "TABS" keywords, the page works as expected, including the DISPLAY_IF items.

Thanks.

(I marked this "trunk", as I've verified it on trunk & trunk+my pending new configure), but I expect the case to fail as far back as the tabbed configure's first appearance.)

# ---+ Menu Test Section -- TABS
# Settings for this test
#---++ Subsection a
# Description a
# **STRING 20**
# Item a1
$Foswiki::cfg{a1} = 'a1';
# ---++ SubTabbed Section S1 -- TABS
# This subsection (S1) appears, but the Selectbox does not make its sub-item display if TABS is set for it.
# **STRING 64**
# Item S1A - part of Subsection 1
$Foswiki::cfg{s1a} = 's1a - in Subsection S1';
#
# **SELECT TypeA,TypeB**
# Select a type to display alternative items.
$Foswiki::cfg{s1aType} = 'TypeA';
#
# ---+++ SubTab Section S1SA
# This is subsection S1SA, the left subtab of S1.<br>
# It displays, but the selectbox does not make its items appear.<br>
# This text, however, does not appear.<br>
# Further, clicking on either subtab (S1SA or S1SB) makes the whole
# page disappear.
# Section S1SA
# **PATH DISPLAY_IF {s1aType}=='TypeA'**
# Type A display item
$Foswiki::cfg{s1aTypea} = 'Display if Type A AAAAAAAAA';
# **PATH DISPLAY_IF {s1aType}=='TypeB'**
# Type B display item
$Foswiki::cfg{s1aTypeb} = 'Display if Type B BBBBBBBBBBBBBBBBBBBBBBB';
#
# ---+++ SubTab Section S1SB
# This is secton S1SB, the middle subtab of S1. <br>
# This subsection cannot be displayed if TABS are set for S1.
# **PATH**
# Item S1B
$Foswiki::cfg{s1b} = 's1b';
#
# ---+++ SubTab Section S1SC -- TABS
# This is secton S1SC, the right subtab of S1. <br>
# This subsection cannot be displayed if TABS are set for S1.
#---++++ Subtab level 4 A
# This is subtab level 4 A
# **PATH**
# Item s4a1
$Foswiki::cfg{s4a1} = 's4a1';
#
#---++++ Subtab level 4 B
# This is subtab level 4 b
# **PATH**
# Item s4b1
$Foswiki::cfg{s4b1} = 's4b1';
#
#---++ Subsection b
# This is subsection b, the right level 2 tab
# **PATH**
# Item b1
$Foswiki::cfg{b1} = 'b1';

1;

Here are some screen captures of the behavior

  • Untabbed view:
    Untabbed.PNG

  • Tabbed:
    Tabbed.PNG

  • Tabbed after clicking a subtab link:
    Tabbed-after-click-subtab.PNG

-- TimotheLitt - 30 Oct 2012

The interface becomes more convoluted. I am not happy with the multiple button rows that we currently have. But I am afraid that additional buttons in the content area are the tipping point.

Some alternative proposals have been offered and I would like to find an alternative, but I am held up because I should wait for your checkin...

For now, do you really need to have the content tabbed? Or can you put the content below each other?

Perhaps similar to jQuery plugin settings, that are grouped with headers:

configure-jquery.png

-- ArthurClemens - 30 Oct 2012

Thanks. Also thanks for waiting for my checkin - sorry to hold you up, but as you know, every svn update brings in more challenges...

The reason I really want sub-tabs is that the screen gets to be very long (in the real case), even with DISPLAY_IF condensing; the information is logically grouped that way; and I'd actually like to make whole sub-tabs disappear if things aren't selected that need them.

I actually think that tabs do a good job of organizing the interface in this case.

To get a feel for the application, here is (the subset I can show with the current bug) what the real screen looks like. It depends on configure plugins not yet in the mainline. What you'll see is that http vs. https determines whether SSL certificates are needed at all.

If the server uses https, it needs certificates, which have a bunch of paramenters (files, password). But then client verification adds another group of certificates. And then there are encryption types, debugging conections...

The TWiki version uses headings, and it's very cluttered and hard to follow.

I've posted both screenshots and the real Config.spec for you to consider. (There are some artifacts because I stitched together several screenshots and didn't aim for perfection.)

Note that both versions are only populated with development tasks; The amount of data will grow in production. Also, the spec doesn't tell the whole story; Configures's Off-line tasks 'Pluggable' finds more spec files and dynamically adds more items... Tabs are really good for organizing all this...

  • TWiki (minimal) interface:
    TWikiInterface.png

  • Foswiki equivalent with tabs and selective display:
    FoswikiInterface.PNG

# ---+ Off-line Tasks -- TABS
# Settings for the off-line task execution framework
# <P>
# Foswiki performs background maintenance tasks using a system daemon.  This section configures the daemon,
# its built-in tasks, as well as add-on tasks supplied by other Foswiki plugins/extensions.
#
# <P> <u>Please return to this page after changing any configuration item in this section</u>, 
# as many configuration diagnostics and confirmations are provided.  
#
# <P>Common to all tasks are schedule items, which specify the schedules on which you want these tasks run.  Sechedule
# items use the time spec portion of vixie-cron <b><i>crontab</i></b> format.  <br />You may find more documentation
# of this format using <b><i>man 5 crontab</i></b> on a unix/linux system.
# <p> Although crontab format is used, the fields are displayed in a more intuitive order here.  Note that you can specify
# multiple values in the drop-down controls, except '*', which matches any time and stands alone.
#<p> The next several tabs configure the daemon and its sub-components.  If you have a complex environment or need
# to debug the daemon or its add-ons, you may need to adjust the <b>expert</b> settings
#---++ Task execution environment
# These settings define the execution environment for tasks.
# **STRING 20**
# Login Name (not WikiName) of user under which tasks are scheduled.
$Foswiki::cfg{Tasks}{UserLogin} = $Foswiki::cfg{AdminUserLogin};
# **STRING 30**
# Task administrator's e-mail address e.g. <code>webmaster@example.com</code> or
# <code>"Web Supervisor" &lt;webmaster@example.com&gt;</code>
# Output from off-line tasks will be e-mailed to this address (like cron).
# <br />If blank, {WebMasterEmail} will be used.  May be over-ridden by task.
# NOTE: must be a single valid email address
$Foswiki::cfg{Tasks}{AdministratorEmail} = '';
# **OCTAL EXPERT**
# File security (umask) for files written by tasks.  Should generally prevent world access.
$Foswiki::cfg{Tasks}{Umask} = 007;
# **SELECTCLASS Foswiki::Tasks::Watchfile::***
# File monitoring can be done by the default polling class or by a system-specific driver 
# that interfaces to the file system's monitoring facilities.  On Linux, this is <i>inotify</i>.  When available, the file
# system's monitoring is more efficient and more timely.
# <p>  Using the file system's monitoring requires installation of a perl interface module and a
# task daemon driver.  <p>The following selection box includes all installed task daemon drivers.
# After selecting one and saving the configuration, run configure again.  Errors will be
# indicated if the one you selected is missing any of its dependencies.
$Foswiki::cfg{Tasks}{FileMonitor} = 'Foswiki::Tasks::Watchfile::Polled';
#---++ Daemon logging and control
# **PATH**
# Log file for serious errors (what would go to the webserver error log if running under a webserver). %DATE% gets expanded
# to YYYYMM (year, month), allowing you to rotate logs.
$Foswiki::cfg{ErrorFileName} = '$Foswiki::cfg{DataDir}/error%DATE%.txt';
# **NUMBER EXPERT**
# The Task Framework maintains an event log in memory for status and debugging.  
# Specify the size of the in-memory log (in lines).  Note that this does
# not limit what is written to log files.
$Foswiki::cfg{Tasks}{LogBufferSize} = 125;
# **STRING 40 EXPERT**
# File name used in the URL to access the daemon for startup.  The full URL used is {DefaultUrlHost}{ScriptUrlPath}/this item.
$Foswiki::cfg{Tasks}{StartupUrlName} = 'TaskDaemon';
# ---++ Daemon Networking -- TABS
# The daemon contains a built-in webserver, which is used by the Foswiki plugin for Foswiki topics that allow you to monitor and
# manage the daemon.
# This is <b>not</b> a general purpose webserver, and does not need to be accessible to Foswiki users.  
# **STRING 64**
# Hostname & port for daemon control.  This is the address on which the daemon listens,  Specify
# 0.0.0.0:<i>port</i> to listen on all IPV4 addresses, [::]:<i>port</i> to listen on all IPV6 addresses, 
# or use a specific hostname or address to listen on only one.  IPV6 addresses must be in []s.
# The port number must be specified, and the webserver user must be permitted to use it.
# This is used for daemon administration, not general users.  <code>localhost</code> is recommended if http is used, but
# note that this is restrictive.  If https is used, server certificate must match this hostname since clients do host
# verification.
$Foswiki::cfg{Tasks}{StatusServerAddr} = 'localhost:1026';
# **STRING 64**
# Hostname and port used to <em>connect to</em> the daemon control port.  Must <em>not</em> be 0.0.0.0,
# and must resolve to one of {Tasks}{StatusServerAddr}'s endpoints.
$Foswiki::cfg{Tasks}{StatusAddr} = 'localhost:1026';
# **SELECT https,http**
# Protocol for daemon control.  Use https if at all possible for security - specify server details in the following items.
# Use http only if https is not available - in which case, we recommend setting {Tasks}{StatusServerAddr} to <code>localhost</code>.
$Foswiki::cfg{Tasks}{StatusServerProtocol} = 'http';
# ---+++ Server Certificate
# **PATH DISPLAY_IF {Tasks}{StatusServerProtocol}=='https'**
# X.509 status server certificate file, only required for https.  Must be in PEM format; can be world readable.
# <p>If your issuer requires an intermediate CA certificate(s), include them in this file after the server's certificate in order from least to most authoritative CA.
$Foswiki::cfg{Tasks}{StatusServerCertificate} = '';
# **PATH DISPLAY_IF {Tasks}{StatusServerProtocol}=='https'**
# X.509 status server private key file, only required for https.  Must be in PEM format with strict permissions.
$Foswiki::cfg{Tasks}{StatusServerKey} = '';
# **PASSWORD 64 DISPLAY_IF {Tasks}{StatusServerProtocol}=='https'**
# X.509 status server private key password, only required for https if {Tasks}{StatusServerKey} is encrypted.  This is does not
# provide much security because (unfortunately) this configuration entry is not encrypted.  
$Foswiki::cfg{Tasks}{StatusServerKeyPassword} = '';
# **BOOLEAN DISPLAY_IF {Tasks}{StatusServerProtocol}=='https'**
# Require verification of client certificates by the status server, available and optional for https.  If you enable this
# option, you must provide a <b>client</b> certificate for the daemon and the TasksPlugin to use for management.
# You must also specify either a Certificate Authority file or path in the items after this.  And {Tasks}{StatusAddr}
# needs to be verifiable from {Tasks}{StatusServerCertificate}, unless it is <code>localhost</code>.
$Foswiki::cfg{Tasks}{StatusServerVerifyClient} = 0;
# ---+++ Client Certificate
# **PATH  DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient}**
# X.509 client certificate file containing the certificate that the daemon itself uses.  Only required for https with
# client certificate verification enabled.  Must be in PEM format; can be world readable.
$Foswiki::cfg{Tasks}{DaemonClientCertificate} = '';
# **PATH DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient}**
# X.509 client private key file containing the private key of certificate that the daemon itself uses.  Only required for https with
# client certificate verification enabled.  Must be in PEM format; with strict permissions.
$Foswiki::cfg{Tasks}{DaemonClientKey} = '';
# **PASSWORD 64 DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient}**
# X.509 daemon client private key password, only required for https if {Tasks}{DaemonClientKey} is encrypted.  This is does not
# provide much security because (unfortunately) this configuration entry is not encrypted.  
$Foswiki::cfg{Tasks}{DaemonClientKeyPassword} = '';
# ---+++ Client Authorization
# **PATH  DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient}**
# Certificate authority file containing one or more certificates of CAs acceptable for client certificate verification.
$Foswiki::cfg{Tasks}{StatusServerCAFile} = '';
# **PATH  DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' &&{Tasks}{StatusServerVerifyClient}**
# Directory containing certificates of CAs acceptable for client certificate verification.  May also contain CRLs.
# Must be hashed (see the OpenSSL documentation).  {Tasks}{StatusServerCAFile} is a simpler alternative.
$Foswiki::cfg{Tasks}{StatusServerCAPath} = '';
# **BOOLEAN  DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient}**
# Require client certificate verification to check for revocation using the issuer's CRL.
$Foswiki::cfg{Tasks}{StatusServerCheckCRL} = 0;
# **PATH  DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient} && {Tasks}{StatusServerCheckCRL}**
# Certificate revocation list file for client certificate verification.  If {Tasks}{StatusServerCAPath} contains CRLs,
# leave this blank.
$Foswiki::cfg{Tasks}{StatusServerCrlFile} = '';
# **REGEX FEEDBACK="Re-test" 128 /DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient}**
# If the client certificate must be issued by a particular party, enter a regular expression to specify what issuer(s)
# are acceptable.  The actual issuer string of a certificate can be obtained using <code>openssl x509 -issuer</code>.
# Leave empty if any issuer is acceptable.  Note that this still requires the issuer's certificate to validate.  Also,
# note that the <b>client</b> certificate used by the daemon itself must satisfy this expression.
$Foswiki::cfg{Tasks}{StatusServerClientIssuer} = '';
# **REGEX FEEDBACK="Re-test" 128 /DISPLAY_IF {Tasks}{StatusServerProtocol}=='https' && {Tasks}{StatusServerVerifyClient}**
# If the client certificate's subject must be validated, enter a regular expression to specify what subject(s)
# are acceptable.  The actual subject string of a certificate can be obtained using <code>openssl x509 -subject</code>.
# Leave empty if any subject is acceptable.  Note that this still requires the subject's certificate to validate.  Also,
# note that the <b>client</b> certificate used by the daemon itself must satisfy this expression.
$Foswiki::cfg{Tasks}{StatusServerClientSubject} = '';
# ---+++ Advanced Parameters
# **SELECT TLSv1,SSLv3 EXPERT /DISPLAY_IF {Tasks}{StatusServerProtocol}=='https'**
# SSL protocol version.  TLSv1 is prefered; SSLv3 may be used for compatibility with some very old web browsers, but is not
# recommended.
$Foswiki::cfg{Tasks}{StatusServerSslVersion} = 'TLSv1';
# **STRING 80 EXPERT /DISPLAY_IF {Tasks}{StatusServerProtocol}=='https'**
# X.509 status server cipher list.  Specifies the acceptable ciphers for SSL connections.  See the OpenSSL documentation
# (<code>man ciphers</code>) for details.  Default is high security; you would need to adjust only if high security ciphers
# aren't available in your locale.
$Foswiki::cfg{Tasks}{StatusServerCiphers} = 'RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL';
# **BOOLEAN EXPERT**
# For debugging tasks (and the daemon itself), this enables a special server that provides a telnet
# command line interface to the running daemon.  <em>Do not enable this on a production system</em>.
# This is an interface for programmers and permits unrestricted access to the webserver account.
# Do <em>not</em> enable this unless you control access to the server, have complete and <em>tested</em>
# backups, and are able to take responsibility for any adverse consequences.
$Foswiki::cfg{Tasks}{DebugServerEnabled} = 0;
# **STRING 64 EXPERT /DISPLAY_IF {Tasks}{DebugServerEnabled}**
# Hostname & port for daemon debugging.  This is the address on which the daemon debugger listens,  Specify
# 0.0.0.0:<i>port</i> to listen on all IPV4 addresses, [::]:<i>port</i> to listen on all IPV6 addresses, 
# or use a specific hostname or address to listen on only one.  IPV6 addresses must be in []s.
# The port number must be specified, and the webserver user must be permitted to use it.
# This is used <em>only</em> for programmers, not for administrator or for general users.  
# <code>localhost</code> is <em>strongly</em> recommended.
$Foswiki::cfg{Tasks}{DebugServerAddr} = 'localhost:1042';
# **REGEX 64 EXPERT /DISPLAY_IF {Tasks}{DebugServerEnabled}**
# If daemon debugging is enabled, the configure password is required to access the debugger.  
# If you are in a <em>very</em> safe environment (such as an isolated virtual machine on a single-user
# system) you may prefer to eliminate the password requirement when connecting from trusted hosts.
# <p>This amplifies the danger of enabling the debugger since it provides access to the webserver's
# privileges with no password security.  If, despite this warning, you want to trust one or more
# hosts, enter a regular expression for those hosts here.  Note that you must match the remote port number
# as well as the hostname.  E.g. <code>^(?:(?:trusted1|trusted2)\.example\.com|localhost):\d+$</code>
$Foswiki::cfg{Tasks}{DebugTrustedHost} = '';
# **STRING EXPERT /DISPLAY_IF {Tasks}{DebugServerEnabled}**
# Group name required to access PTY devices (for debugging).  Only set if necessary, must also put webserver user into
# this group if it is.  Not required for Linux.
$Foswiki::cfg{Tasks}{DebugTtyGroup} = '';
# **STRING 80 EXPERT /DISPLAY_IF {Tasks}{DebugServerEnabled}**
# If you need to debug an externally-scripted task (instantiated with <code>command => 'scriptname'</code>)
# using the perl debugger, you may need to specify where the debugger's terminal window is created.
# <p>If you are running a private copy of the daemon (e.g. -f), your terminal window will be used and
# this configuration item will be ignored.
# <p>Otherwise, set this configuration variable according to your operating system:
# <ul>
# <li>  X-window system (most Unix OSs): <code>TERM=xterm|DISPLAY=:0.0</code>.  The value for DISPLAY can
# be any DISPLAY supported by your  system.  Often <code>echo $DISPLAY</code> in a terminal window will provide the value you need.
# Don't forget to set =.Xauthority= for the webserver account.  You can set <code>XAUTHORITY=/path/.Xauthority</code> here if
# necessary, but be careful that permissions are set correctly.
# <li> Apple systems (Leopard or later): <code>TERM_PROGRAM=Apple_Terminal|TERM_PROGRAM_VERSION=237</code>
# Use <code>echo $TERM_PROGRAM;echo $TERM_PROGRAM_VERSION</code> in a terminal window to verify these values for your system.
# </ul>
# You must also activate the perl debugger with <code>-w</code> in the <code>#!</code> line of your script.
$Foswiki::cfg{Tasks}{DebugTerminal} = '';
#---++ Built-in tasks
# Tasks included in the base product.
#
# **SCHEDULE**
# Schedule for internal tasks (previously run by tick_twiki) such as expired sessions and edit locks.
# <br />
# Also the cleanup schedule used by simple plugins.
# <br />
# The default is to run at 01:15:14 every 3 days.
$Foswiki::cfg{CleanupSchedule} = '1 15 1-31/3 * * 14';
# **SCHEDULE EXPERT**
# Times at which the daemon checks for configuration changes and polls other events when an asynchronous notification
# mechanism is not available.  
$Foswiki::cfg{Tasks}{PolledEventsSchedule} = '*/5 * * * * 17';

#---++ Add-on tasks
# Task interface modules supplied by other add-ons/extensions/contribs.<br />
# The following extension interfaces were detected:
# *TASKS* Marker used by bin/configure script.
$Foswiki::cfg{Tasks}{Tasks}{NoTaskListMarkerDontDeleteMe}{enabled} = 0;
## The above entry is necessary for the spec parser to work, but since there is
## no file of that name, it doesn't do any harm.

1;
-- TimotheLitt - 30 Oct 2012

This is working fine now in the latest new & improved 1.2 configure. One more rewrite, and now it's a jsonrpc application, tabs are rendered by javascript only when accessed.

-- GeorgeClark - 08 Oct 2014
 

ItemTemplate edit

Summary Configure TABS don't work at level 3+
ReportedBy TimotheLitt
Codebase trunk
SVN Range
AppliesTo Engine
Component Configure
Priority Normal
CurrentState No Action Required
WaitingFor
Checkins
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release01x01Checkins
I Attachment Action Size Date Who Comment
configure-jquery.pngpng configure-jquery.png manage 90 K 30 Oct 2012 - 12:43 ArthurClemens  
Topic revision: r4 - 08 Oct 2014, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy