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

[Gunther B. <gu...@ex...>]

I disagree in general with this. Having coded a lot of WML and HTML myself 
for a local mobile company, I can say pretty strongly that I do not believe 
in a 1-1 mapping between elements in WML and HTML except in a very loose sense.

You really have to code the whole template very separately for WML vs HTML 
and the choice you make (eg textfield vs textarea) is very different on WML 
vs HTML.

So you would not want some generic Widget::TextField that rents a WML 
version for WML and HTML for HTML. It's quite possible that on web you may 
want to allow the user to type in a lot of info in textarea but on wap, you 
just restrict it a bit more.

I think for most programmers, it will be easier to see HTML widgets and 
then dive in there and then plainttext widgets and WAP widgets etc as a 
substructure and then see when they are coding an HTML form what elements 
are available to them when they are doing so.

Later,
       Gunther

At 10:41 PM 6/4/01 -0500, James G Smith wrote:
>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

__________________________________________________
Gunther Birznieks (gun...@eX...)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/