Tags:
create new tag
, view all tags

Feature Proposal: Configure Features for Task Framework

Motivation

The tasking framework grew out of the garbage collection for plugins feature proposal. I intend to make it available as an extension - technically a "plugin", although it's a hybrid plugin/contrib/something-else.

However, several minor patches are required to configure for the task framework to function. I'd like these to be in the core - I don't want to distribute or maintain core patches.

These changes are generally useful and backward compatible.

Note that this topic is much larger than the code changes, which are 13 and 7 lines respectively...including the bug fixes that came along for the ride.

Description and Documentation

  1. UI.pm
    • add "use Carp" : Existing code uses Carp but relies on some other module to use it. Breaks tests.
    • Add makeChecker probe to checker factory (loadChecker). Currently, any configure item that requires a checker must have a unique checker class. This is a lot of work for the developer (and a lot of files for configure to load), particularly when there are many instances of an item that does not requre item-specific information to be checked. As a result, many items that could have checkers, don't. SCHEDULE items in the task framework are the immediate motivation. The code change causes loadChecker to ask the Type class if it can fabricate a generic checker for an item that would otherwise not have one. If Type can, it's asked to do so. Thus, any item-specific checker (the only kind currently existing) takes precedence.
  2. Valuer.pm
    • \ a { in a TYPEOF regex - current code is relying on an oversight of the perl parser
    • Add ability of an item's string2value method to receive the entire query, not just it's $query->param item. This allows a configuration item's value to be synthesized from several form fields, which is currently impossible. The alternate call is conditioned on a flag set in the Type by items which require this functionality.
These are both internal changes to the configure infrastructure and should have no impact to existing users or developers.

The patch implementing both changes is attached.

Examples

Here are use cases extracted from lib/TWiki/Configure/Types/SCHEDULE.pm

Enabling query argument:

sub new {
    my ($class, $id) = @_;

    my $self = bless({ name => $id }, $class);

    # Make Valuer.pm call string2value with query and item name
    # This enables us to find all the sub-fields in POST data

    $self->{NeedsQuery} = 1;
    return $self;
}

Checker factory:

# When no item-specific checker class exists,
# This method can generate one since no key-
# specific information is needed.  This reduces
# the clutter (and effort) of creating one trivial
# class per key.

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;
}

Synthesizing an item from multiple form fields:

# Normally turns a string into a value
#
# In our case, we'll look for the string in the query ourself,
# and build it from pieces if possible.

sub string2value {
    my( $this, $query, $name ) = @_;

    my $xid = $name;
    $xid =~ tr /\{\}/()/;

    die "Query not available; is lib/TWiki/lib/Configure/Valuer.pm up-to-date?" unless( ref $query  eq 'CGI' );

    # If we don't have the listbox values (dow is arbitrary), we use whatever's in the full string.
    # We computed that in a previous screen.
    # If we do have the listbox values, it's a config change form, so piece the string together.

    return $query->param($name) unless( defined $query->param( $xid.'dow' ) );

    my $value = '';

    # crontab order, build record from each field

    foreach my $field (qw /min hour dom mon dow sec/) {
        $value .= ' ' unless( length $value == 0 );
        my @values = $query->param( $xid.$field );
        @values = '*' unless( @values );
        $query->delete( $xid.$field );

        # condense the value list using ranges and repeat counts

        $value .= _condense( @{ {
                                    hour => [ \%numMap, 0, 23 ],
                                    dom =>  [ \%numMap, 1, 31 ],
                                    dow =>  [ \%dayMap, 0, 6 ],
                                    mon => [ \%monMap, 1, 12 ],
                                }->{$field} || [ \%numMap, 0, 59 ]
                              }, @values );
    }
    $query->param($name,$value);

    return $value;
}

Impact

(Internals only) Enables configuraton of task framework extension.

Implementation

See attached: Patch file to implement against trunk revision 21843

-- Contributors: TimotheLitt - 2011-07-27

Discussion

This feature was accepted by IstanbulReleaseMeeting2011x08x01 even though it was posted after the code freeze. The exception is based on:

  • very low risk - the code has been running in Timothe's development environment for several months
  • patch provided against trunk

-- PeterThoeny - 2011-08-01

The attached patch is now in SVN trunk. Thank you Timothe! I presume only the patch needs to go in, not the examples above.

Timothe, please do an svn up and test.

-- PeterThoeny - 2011-08-01

Thanks Peter.

You are correct, this feature proposal only requested merging the patch file.

The examples are extracted from a file that is not part of the the core (it's part of the TFW). They were provided only to document the use cases for the core changes.

I've done an "svn update" and verified that the patches were applied properly.

The BugTracking link below is invalid. I think you meant TWikibug, not TWiki...

Thanks for doing the merge.

-- TimotheLitt - 2011-08-01

Yup, interwiki link fixed.

-- PeterThoeny - 2011-08-01

Is this proposal still relevant? Or is it covered by new TasksFramework proposal?

-- PeterThoeny - 2012-09-14

This is done. It is enabling technology for the TasksFramework.

If the framework is used as an add-on, it would have required these patches to the core Configure modules.

Assuming it's integrated, it depends on these.

Either way, they're in the code and no further action is required at this time.

-- TimotheLitt - 2012-09-30

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch tfwconfigure.patch r1 manage 2.1 K 2011-07-27 - 10:35 TimotheLitt Patch file to implement against trunk revision 21843
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2012-09-30 - TimotheLitt
 
  • 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.