[Perl-widget-developer] Widget.pm design
Status: Alpha
Brought to you by:
spadkins
|
From: James G S. <JG...@TA...> - 2001-06-05 04:11:58
|
I'm looking through the code a bit closer finally. I had some
thoughts and a diff showing some of the code that comes out of
them - plus a few things that might make the code a but more
readable (it is fairly readable already, but I had to stop and
think through one or two things once in a while).
Instead of Widget::HTML::Element, I think I'd prefer to see
Widget::Element::HTML. We could think of `Element' as the widget
archetype.
Pro:
(1) Easier widget creation. Instead of having to supply the
full class name when using the create method, you can pass the
type of element and the create method can build the class name.
(2) Easier packaging and distribution of third-party widgets.
(3) (1) makes creating aggregate archetypes easier.
(4) Consolidation of logic.
Con:
(1) HTML widgets are spread out, as are XML widgets and WML
widgets. No longer are all the widgets for a particular output
environment in one namespace.
Note (4) above needs some more commentary.
If we have Widget::Base as the base object for Widgets, then we
can have Widget::Base::HTML as the base for the HTML
specialization of Widgets. It could contain the html encoding/
decoding code and other HTML specific functions.
Widget::Element is a Widget::Base while
Widget::Element::HTML is a Widget::Element and Widget::Base::HTML.
Widget::Element has all the processing logic for the widget while
the tertiary modules (::HTML, ::WML, etc.) contain the output
logic.
There might also be good reason for moving the create method to
the controller object. It knows more about the environment than
Widget does and can create the correct widgets given the
archetype requested. See the diff for one possible solution to
the problem of a non-existant class.
--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
*** Widget.pm.dist Mon Jun 4 22:11:23 2001
--- Widget.pm Mon Jun 4 22:23:28 2001
***************
*** 69,75 ****
my $self = shift;
my ($args);
! if ($#_ == -1) {
$args = {};
}
elsif (ref($_[0]) eq "HASH") {
--- 69,75 ----
my $self = shift;
my ($args);
! if (!@_) {
$args = {};
}
elsif (ref($_[0]) eq "HASH") {
***************
*** 129,139 ****
return $self->create($args->{controller}, $args);
}
sub create {
my $self = shift;
my $class = shift;
# TODO: what should I really do here if the class does not exist?
! return undef if (!Widget->use($class));
return $class->new(@_);
}
--- 129,148 ----
return $self->create($args->{controller}, $args);
}
+ # Question: Does the create function belong in the controller?
+ # Re: The controller knows what kind of widgets are needed (HTML,
+ # XML,Gtk+, etc.)
sub create {
my $self = shift;
my $class = shift;
# TODO: what should I really do here if the class does not exist?
! if(!Widget -> use($class)) {
! # TODO: figure out how we want to sub-class Widget::$class...
! # This does assume Widget::Thingy::HTML instead of
! # Widget::HTML::Thingy.
! $class = join("::", "Widget", $class);
! return undef unless Widget -> use($class);
! }
return $class->new(@_);
}
***************
*** 149,156 ****
$file = $class;
$file =~ s#::#/#g;
$file .= ".pm";
! require $file;
! $ok = 0 if (! defined $INC{$file});
}
$ok;
}
--- 158,164 ----
$file = $class;
$file =~ s#::#/#g;
$file .= ".pm";
! $ok = 0 unless require $file;
}
$ok;
}
***************
*** 185,191 ****
print STDERR "Widget->html() $item => ref=[$ref]\n" if ($Widget::DEBUG);
next if ($ref eq "CODE" || $ref eq "GLOB"); # TODO: are there others?
! if ($ref eq "" || $ref eq "SCALAR") {
# TODO: find out what other transforms are in the standard
$elem = $item;
# borrowed from CGI::Util::simple_escape() ...
--- 193,199 ----
print STDERR "Widget->html() $item => ref=[$ref]\n" if ($Widget::DEBUG);
next if ($ref eq "CODE" || $ref eq "GLOB"); # TODO: are there others?
! if (!$ref || $ref eq "SCALAR") {
# TODO: find out what other transforms are in the standard
$elem = $item;
# borrowed from CGI::Util::simple_escape() ...
|