Re: [Perl-widget-developer] Widget.pm design - Widget::HTML::Element vs Widget::Element::HTML

[Jay L. <Ja...@La...>]

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
>