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

[<ce...@si...>]

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

Well, dictionary.com defines it as such:

 2. [possibly evoking "window gadget"] In graphical user interfaces, a
combination of a graphic symbol and some program code to perform a
specific function. E.g. a scroll-bar or button. Windowing systems usually
provide widget libraries containing commonly used widgets drawn in a
certain style and with consistent behaviour.


I think that is a simple enough start.  But there is a bit of a difference
in what we are trying to do, and what constitutes a conventional Widget
Library.  We are taking existing Widgets and 'beefing' them up.
Essentially, we are making a Widget Convenience Class, that gives us a
bridge between the user-interface and the back-end code.

Part of this is giving the widgets persistence, making them Multilingual,
or providing them with theme support.  And the other part of it is taking
the existing widgets, and building more complex widgets (taking a select
box widget, and making a date widget out of it).

But the end result we should be aiming at, is a library that will make it
easiers for programmers and designers to build user-interfaces in perl
(with a heavy slant to the HTML programmer/designer).


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

I think it will take more than a week of working together before any group
of individuals can consider themselves a team.  Especially since everyone
is working remotely.  The fact that we have a working codebase is a good
sign (Thanks mostly to Stephen).  I think it will become easier once
everyone finds a corner of the code where they feel comfortable, and where
they can expose their strengths. 


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

> Also, I have called it the Perl Widget Library.

This is a good enough name for me.  If I was searching for a project that
would help me build widgets in perl, those are probably the exact three
words I would type into google.


> #3. Let's agree about Why We Are Doing This.

This might sound selfish, but I am doing this because I want to build on
my perl skills.  I wrote my first perl program back in '94, but I have
mostly worked on projects by myself.  I feel I can learn a lot from
working on a distributed project.  

Mind you, I also think this project will be useful in my 9 to 5 job when
it is finished :)


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

Yes.  We need to see how the library will be used before we can see how to
develop the inards.

2 things about the above code (I have addressed these issues in my patch
from earlier today).  I think we should use the hash method of providing
options to a constructor (but not a hashref).  Also, I think that any
aspect of the widget should be configureable from the code so that a
configuration file is optional.  This will have some implications on the
current caching mechanism (if I call on the same widget with different
options but the same name, what should I get back?)

use Widget;
$wc = Widget->controller(-cgi => $cgi);
$birth_dt = $wc->widget(
    -name    => 'birth_dt',
    -default => '1970-01-01',
    -format  => 'YYYY-MM-DD',
);
print $birth_dt->display();


I would like to open up the debate about the use of 'display' or 'html'
again.  I am wondering about the possibility of confusion between
'displaying' the code that generates the widget, and 'displaying' the
value of the widget.  Also, display() seems to imply a print.  What if we
got rid of both html() and display() and used draw() or render() for
generating the code, and leave value() as it is.  Or, if you want, you can
shoot me for opening up this can of worms again :)


> #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 will leave this section blank while we are working on number 5...


Cees Hek