[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() ... |