Re: [Perl-widget-developer] How are we going to come up to speed as a team?

[Stephen A. <ste...@of...>]

At 10:21 PM 6/2/2001 +0200, Issac Goldstand wrote:
>Stephen:
>
>  Maybe put a bit of general info either on the list or somewhere on
>sourceforge explaining what you're expecting your base classes to grow
>towards... It would help me, at least, get a better understanding of what
>you've done, and hopefully get us all, as a team, focused on a single vision
>of the what's and how's of implementing this in a consistant form...  I
>personally am still unsure of what some things in the base classes are meant
>to do...
>
>  Issac
>

Hi,

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

So how are we going to come up to speed as a team?

#1. Read the Perl Widget Library home page periodically.
    I have updated it in the last 48 hours with many relevant statements.

    http://www.officevision.com/pub/Widget/

#2. Let's agree on *what* we are building and *what* we will call it.

What is it? A library of useful HTML user interface widgets, 
and a framework for extending them and developing your own.

This is a simple statement that I think is accurate, simple, and attractive
to those who might want to use it.

Also, I have called it the Perl Widget Library.

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 looked to precedent and took note of the "Perl Data Language".
That's how I came up with the "Perl Widget Library" as the name.

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

#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.

Please also see the "cgi-bin" and "examples" directories for example
usage.

By the way, you can see the "cgi-bin/cgisample" script running at

   http://www.officevision.com/cgi-bin/pub/Widget/cgisample

It doesn't look very exciting yet, but it will.

#5. Let's address changes in *usage* first.

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.

Sounds like a plan?

Stephen