[Perl-widget-developer] Wrappers vs Core Widget Code was Re: [Perl-widget-developer] How are we going to come up to speed as a team?

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

At 11:51 AM 6/3/01 -0400, Jay Lawrence wrote:
>Hey all,
>
> > I see lots of enthusiasm for widgets and not much consensus on what they
> > are or how they work (or how they're built on the inside).
>
>I belive that since we are all technologist we collectively fall into the
>trap of salivating over the delicious details of how to solve the problem
>without establishing what the problem is. I will later demonstrate how I am
>not immune from this effect. ;-)
>
>All this talk about how to do this and that and sample code makes me nervous
>about the success of the project. I think we have to take our time, pause
>and reflect on our concepts before slogging away at massive amounts of code.

I don't know if the code is massive at the moment. It's more proof of 
concept to lend concreteness to the discussion.

> > #2. Let's agree on *what* we are building and *what* we will call it.
>
>I'd even suggest we talk about the name - Widget is utilitarian and
>unmarketable. Annecdote: I tested a friend of mine who last night does a wee
>bit of web development. He's heard of JavaBeans but never hear of Perl. A
>testiment to the power of marketing and buzzwords.

I don't think we have Sun's marketing department to push a name and 
branding amongst the other things to make it succeed.

>Why would I/we possibly care? Well because Perl has way less acceptability
>compared to Java in most IT environments that _I've_ encountered. One of the
>results of this project should be a solid and extensible software component
>strategy that allows for the development of small and simple as well as
>large and complex applications that are more efficient to maintain and
>reliable.

Well, this is Perl advocacy and I don't think anyone would disagree that 
Java has the marketing upper hand. I am not sure branding a widget library 
for Perl is going to help Perl unless that Branding is clear, consistent, 
and most importantly, pushed. Where the last part takes a lot of energy.

>If we go to all this work to make reusable interface components for Perl we
>want to *sell* it to our bosses, directors, clients, whoever. Give 'm a
>meaty name that speaks "faster, better, easier". Something that they're
>gonna be able to refer to again and again as a progressive concept. Widget
>says "thinggy" which is not exactly telling the non-perl programmer "Hey
>this is gonna make everybody's job easier and better" without extensive
>embellishment of the name.

And whose domain name isn't taken. :)

> > What is it? A library of useful HTML user interface widgets,
> > and a framework for extending them and developing your own.
>
>It is a strategy for deploying reusable interface elements which are easy to
>use and easy to develop.

Well, this is where we differ. I think the former is what I want. And the 
latter is more akin to Zope or a content management system. I think it's 
possible that the former can become the latter or be a part of the latter, 
but it just seems a bit scary to me until someone were to commit to really 
doing the equivalent to Zope on Perl.

> > The reason is that (1) we chose a top-level package (Widget::*) to build
>it
> > in, and (2) we chose a generic package name (Widget) rather than a
> > "marketing" package name (i.e. DynoWidgets, etc.).
> > If we had chosen a second-level package name (HTML::Widget::*) we could
> > call the package HTML-Widget.  We can't really just call it "Widget".
> > If we had chosen a "marketing" package name, it would hurt the ability
> > of users on CPAN to understand what it was from the package names.
>
>I argue against the fact that it will be difficult to find. If what we
>create is accepted, exciting and compelling the Perl community will market
>it and promote it amonst our own. We should be looking at nothing short of
>making this module an essential install for any sites developing apps.

I think it will be found by virtue of the fact that ANNOUNCE statements 
will be generated so often to the appropriate mailing lists. And then 
people will get interested.

In addition, I don't think we need to do any marketing if stubs are written 
to integrate with various languages. I have little doubt that if there were 
a Template Toolkit stub that widgets wouldn't become quite a prominent 
cross-link from TT pages.

> > Now I considered "Perl Widget Framework".  However, I really don't want to
> > communicated to newcomers that you need to do a lot of development work
> > to get out a widget.  Many (more and more over the years, I should hope)
>
>For most developers - new widget should be as complicated as:
>     - itemize your widget's properties
>     - create your HTML (or other) rendering code
>     - address the few special functions that are unique to your widget
>
>I would hope that many developers will be able to contribute to the widget
>space as well! This is what it is all about!
>
> > widgets will come prepackaged with the kit.  It will come "ready-to-use"
> > right out of the kit.  So the fact that it is a development framework for
> > making your own widgets became secondary to the fact that there were in
> > fact going to be a bunch of nifty widgets ready to use.
> > What we are building really is a Perl Widget Library.
> > (We just have to start with a framework in order to get there.)
> >
> > (more on this in the new FAQ.pod.)
> >
> > #3. Let's agree about Why We Are Doing This.
> >
> > If everyone agrees with 50% of the "Why a Widget Library?" problems,
> > I think we are doing pretty well.  Please suggest others.
> > I want us to agree on what problems we are trying to solve.
>
>I am doing this becuase I know that we're all rolling our own internal
>libraries to do similar things. I see that we can improve Perl's stance as a
>viable language in "real application development" scenarios. I want widgets
>for my code. I want it to be easy to write new widgets too.
>
> > #4. Let's understand the code that is written.
> >
> > As you can see, I have been working a lot on documentation in order to
> > help people understand the framework so far.  I will continue to do
> > this.  Please read the brief descriptions of classes on the Home Page,
> > and let's discuss that.  Please don't make recommendations
> > for changes until you know what exists and why.
>
>I'd like to suggest we leave all of the surrounding controller logic, etc,
>out of this and focus on just widgets themselves at this time.

I think this is correct to some degree. But I think a default controller 
should exist to help you do the things you want to do. My personal feeling 
is that this is where your multilingual switches and other stuff really 
belong.

>Personally - at this point I am just playing with how I can easily implement
>widgets and solve some of those major issues that have been mentioned
>elsewhere.
>
> > #5. Let's address changes in *usage* first.
>
>Again, lets just focus on how individual widgets work and solve the
>connection to state, CGI, configuration, instantiation, etc. later. Stub
>them in and mock them up. THEN you can decide what best makes sense for
>their respective implementation.
>
> > Let's not focus first and foremost on what a "Widget::State::CGI"
> > object is.  Let's focus on whether
> >
> >    use Widget;
> >    $wc = Widget->controller({ cgi => $cgi });
> >    $birth_dt = $wc->widget("birth_dt");
> >    print $birth_dt->display();
> >
> > is the right way to use a widget library.
> > This is really just a code-driven refinement of the Use Cases of the
> > Perl Widget Library.
>
>
> > #6. Let's address changes in *internal design* next.
> >
> > If you understand what is written and why it is that way, I am open
> > to any and all suggestions to change it.
>
>I have a big suggestion on how to implement widgets.
>
>A - use Class::MethodMaker to implement widget properties:
>
>     http://work.evolution.com/dist/Class-MethodMaker-2.0.7.tar.gz
>
>     Why? Its very efficient, its easy to use and it will support the level
>of flexibility that we're demanding. Specifically I am thinking about my
>need for multilingual text properties. I am going to be able to change how
>text values for a widget are defined and will be able to change the way that
>text property accessors are created at my site but the rest of the world can
>use your good ol' unilingual text accessors.

Can this be used optionally by a widget? So that your multilingual widgets 
are coded using this method? The implementation really doesn't matter, it's 
more the interface right?

>B - use meta data to configure your widgets:
>
>package Widget::Slider;
>require Widget::Base; @ISA=qw( Widget::Base );
>
>     # Concept - %props itemizes and describes the settable properties for
>this widget
>     # - type would be a short list, but extensible, list of types of data
>we'd support
>     # - title would be a longer title for this property
>     # - default - the properties default value if none supplied
>     # - user - a flag to say that end users can set this value and would be
>stored in session if it exists
>
>     %props=(
>         minimum => {
>             type => 'numeric',
>             title => {
>                 en => 'Minimum allowable value',
>             },
>             default => 1
>         },
>         maximum => {
>             type => 'numeric',
>             title => {
>                 en => 'Maximum allowable value',
>             },
>             default => 1
>         },
>         value => {
>             type => 'numeric',
>             title => {
>                 en => 'Current value',
>             },
>             default => 1,
>             user => 1,
>         },
>
>         # Somewhere we'd have to register our list of actions that the
>widget
>         # supports, too.
>         increase => {
>             type => 'action',
>             title => {
>                 en => 'Increase current value by increment amount',
>             },
>             user => 1,
>         }
>
>     };
>
># Place this wherever you wish - I just put here for illustrative reasons
># - there are lots of support functions that should be assisting this
>rendering process
># - ie/ icons and href functions
>
>sub display_html {
>     my $self=shift;
>     my $retval="";
>
>     $retval.="<a href='xxx'>\&lt;</a> ";
>     $retval.="<img src='/icons/grey.gif' height='10' width='";
>     $retval.=($self->value - $self->minimum + 1)."'>";
>     $retval.="<img src='/icons/box.gif' height='10' width='10'>";
>     $retval.="<img src='/icons/grey.gif' height='10' width='";
>     $retval.=($self->maximum - $self->value)."'>";
>     $retval.=" <a href='xxx'>\&gt;</a>";
>
>     return $retval;
>
>}
>
># Meta code 2 follow:
>
>package Widget::Base;
>
>     %base_props=(
>         # Same layout as props above but the basic props that _all_ widgets
>will have
>     );
>
>     foreach $prop (keys %base_props) {
>         # push $prop on to lists of properties - by type - to be defined
>     }
>     # Again for subclass' list of props
>
>     # Just a sketch on how C::MM would be called
>     use Class::MethodMaker::Hash (
>         'new' => 'new',
>         'scalar' => \@list_of_scalar_props,
>         # etc
>     );
>
>=cut

I think that these are a separate form of widgets that you might call 
"logical" and they would in term encapsulate data properties.

eg

Widget::Logical::Numeric would encapsulate a text field or text area widget 
(optionally) and then you would add your numeric validation logic to it.

>Anyway - the idea here is that most of the Widget development is focussing
>on:
>     - what are the properties that my widget has
>     - supply detailed descriptions of these properties - think IDE here
>     - supply mandatory methods like - how to render under HTML
>     - supply actions - like increment and decrement

Actions can be done as a wrapper around a widget.

>     All the tough work to define and instanciate a widget would be supplied
>by the Widget::Base class - including adjusting how certain properties get
>created.
>
>If I have made leaps of logic here - please ask away! I am fairly new to
>Class::MethodMaker myself - but it is an extremely exciting module for
>building object classes and is pretty much completely flexible in what it
>can do. I don't think we should use anything else.
Later,
     Gunther