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

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

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.

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

I'd really like to see it stop at "Why a Widget Library" until we know more
about what we're trying to do here.

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

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.

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.

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

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

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

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.

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

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

    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.

My $0.02 CAD which is currently about $0.013072 US.

Jay