But if you could pass arguments, you'd break the sub create {my $self = shift;... paradigm

for my $item (@item) {
  $self->i(++$i);
  inner();
}
[download]

Alternatively, I could always never run the superclass directly and have ::Gtk2 subclass as well as a ::PlainText subclass.

Why would it matter if there is not necessarily an inner class? Assuming the i attribute does not clobber any existing attribute, then this becomes a no-op.

And according to Moose::Manual::BestPractices, you should Always_call_inner_in_the_most_specific_subclass

For the time-being, I have if-then'ed a solution:

sub updateprogress {
    my ($self) = @_;
    return unless $self->progressbar;

    my $frac = frac($self->recordi, $self->recordcount);
    $self->progressbar->set_fraction($frac->num);
}
[download]

and then the data processing loop blindly calls this graphic method:

sub manager {
    my ($Operation) = @_;

    my @row = $Operation->getnew;

    my ( @warnings, @fatals );
    $Operation->recordi(0);
    for my $row (@row) {
        $Operation->recordi( $Operation->recordi + 1 );

        $Operation->data($row);
        $Operation->process;

    $Operation->updateprogress;
    }
    ( \@warnings, @fatals );
}
[download]






The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development.

-- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"

Arunbear's code below works, though I'm a little thrown.

Actually, it doesn't. See my response.