Re: [Perl-widget-developer] Widget.pm design - Widget::HTML::Element vs Widget::Element::HTML
Status: Alpha
Brought to you by:
spadkins
|
From: Jay L. <Ja...@La...> - 2001-06-05 14:06:07
|
I see this the same way as James - put your generic logic in the parent
class and then interface-specific logic in subclasses:
Widget::Element.pm -> generic logic
Widget::Element::HTML.pm -> HTML-specific
When we make widgets I'd expect that
Widget::Element ISA Widget::Base
and
Widget::Element::HTML ISA (Widget::Base::HTML, Widget::Element)
Then if the app is in HTML it would make a new Element widget via:
$element=Widget::Element::HTML->new( { params } )
OR we could make constructor take a hint as to which context the widget is
to be used and return that object type:
# pseudocode:
Widget::Base
sub new {
# constructor logic goes here
# $class will be "Widget::Element" at this point
if ($widget->container->type eq "HTML") {
bless $widget, "$class::HTML";
}
OR
if ($widget->type eq "HTML") {
bless $widget, "$class::HTML";
}
OR
bless $widget, $class."::".$widget->type;
}
I personally don't advocate putting constructor into controller - instead
have the contructor check with the controller. That is the one crucial link
that will supply us all of the environmental details needed.
J
> 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() ...
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>
|