perl-widget-developer

[Perl-widget-developer] thoughts on design

[James G S. <JG...@TA...>]

Here are some thoughts and ideas I've had and played with in 
various forms over the last few months regarding themeing and 
html rendering.  Some things might be useful, some not.

Background:  I am currently working on some PHP code to provide 
an environment in which scripts can be independent from most 
content which, in turn, can be independent of the look of the 
page.  The theme object is called to render anything from form 
input tags to tables.

For a live example, browse https://neo.tamu.edu/xyzzy/ .  This is 
a non-public alpha installation being used for current 
development.  The Directory feature uses the theme object to
render the list of found records in LDAP as well as the actual 
record itself.  You could think of the list as a list widget that 
the theme object provides for the script.

I am currently developing a table rendered in PHP that will 
render using <pre>..</pre> text instead of tables.  This will 
allow for a theme that uses no tables for those browsers that 
have a hard time rendering tables.

In addition to providing some components/widgets for the scripts, 
the theme object also handles the page layout.  At the moment, I 
have enumerated 47 (16 with all edge content intact + 31 with 
some edge component missing) different ways to layout a page with 
central and edge content.  For example, the default look of the 
above development site is as follows:

+---------+
|   Top   |
+---------+
|         |
| Content |
|         |
+---------+
|  Bottom |
+---------+

I don't have the proper data structure initialized for this 
particular layout, but if I did, the user would have the choice 
of having this rendered using frames or tables.  Currently, it 
will only use tables.  This is done without the script or theme's 
knowledge.

http://hex.tamu.edu/test.php has three themes available for 
demostration.  It also shows what the ldap directory object 
returns from a successful lookup (me).

Back to the Present:  I would like to bring as much of this logic 
as possible over into the Perl world.  I think a widget system 
would be a good way to do it.  A theme could possibly be a widget 
factory -- I ask it for a widget that can draw a table, and it 
gives me one.  I don't have to know what the package is or the 
specifics of configuring it, as long as I can give it a set of 
headers and the table contents and it can draw a table for me.

I could give the theme object back a set of widgets and it could 
render the page, allowing for the user to choose frames or no 
frames (for example) without causing drastic problems in the code 
composing the page.  Perhaps this could be done with the template 
idea....

Widgets could still be used outside of the widget factory, but 
the code would need to know which widget it was using.  The 
factory would need to be aware of all the types of widgets being 
used in the site.  It could also handle the burden of doing the 
general configuration of widgets, allowing the scripts to focus 
on the items that make the widget unique/useful in their context.

This could also be done (I think) parallel with other efforts 
such as the Widget::HTML::Template idea (milestone 5).  The two 
might even complement each other.
--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Re: [Perl-widget-developer] thoughts on design

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

James,

Sounds like your thing is Themes.
We want the Themes concept to work its way into the PWL.
Please take a look at the software, Widget-0.01 found at

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

Begin to understand the classes and the existing framework.
Then start proposing on this list

  1. a class or set of classes to implement Themes
  2. XML configuration format to configure Themes

When you understand how the PWL works and we all concur on
how Themes fits in, you can go berzerk.

Stephen

At 10:53 PM 5/31/2001 -0500, James G Smith wrote:
>Here are some thoughts and ideas I've had and played with in 
>various forms over the last few months regarding themeing and 
>html rendering.  Some things might be useful, some not.
>
>Background:  I am currently working on some PHP code to provide 
>an environment in which scripts can be independent from most 
>content which, in turn, can be independent of the look of the 
>page.  The theme object is called to render anything from form 
>input tags to tables.
>
>For a live example, browse https://neo.tamu.edu/xyzzy/ .  This is 
>a non-public alpha installation being used for current 
>development.  The Directory feature uses the theme object to
>render the list of found records in LDAP as well as the actual 
>record itself.  You could think of the list as a list widget that 
>the theme object provides for the script.
>
>I am currently developing a table rendered in PHP that will 
>render using <pre>..</pre> text instead of tables.  This will 
>allow for a theme that uses no tables for those browsers that 
>have a hard time rendering tables.
>
>In addition to providing some components/widgets for the scripts, 
>the theme object also handles the page layout.  At the moment, I 
>have enumerated 47 (16 with all edge content intact + 31 with 
>some edge component missing) different ways to layout a page with 
>central and edge content.  For example, the default look of the 
>above development site is as follows:
>
>+---------+
>|   Top   |
>+---------+
>|         |
>| Content |
>|         |
>+---------+
>|  Bottom |
>+---------+
>
>I don't have the proper data structure initialized for this 
>particular layout, but if I did, the user would have the choice 
>of having this rendered using frames or tables.  Currently, it 
>will only use tables.  This is done without the script or theme's 
>knowledge.
>
>http://hex.tamu.edu/test.php has three themes available for 
>demostration.  It also shows what the ldap directory object 
>returns from a successful lookup (me).
>
>Back to the Present:  I would like to bring as much of this logic 
>as possible over into the Perl world.  I think a widget system 
>would be a good way to do it.  A theme could possibly be a widget 
>factory -- I ask it for a widget that can draw a table, and it 
>gives me one.  I don't have to know what the package is or the 
>specifics of configuring it, as long as I can give it a set of 
>headers and the table contents and it can draw a table for me.
>
>I could give the theme object back a set of widgets and it could 
>render the page, allowing for the user to choose frames or no 
>frames (for example) without causing drastic problems in the code 
>composing the page.  Perhaps this could be done with the template 
>idea....
>
>Widgets could still be used outside of the widget factory, but 
>the code would need to know which widget it was using.  The 
>factory would need to be aware of all the types of widgets being 
>used in the site.  It could also handle the burden of doing the 
>general configuration of widgets, allowing the scripts to focus 
>on the items that make the widget unique/useful in their context.
>
>This could also be done (I think) parallel with other efforts 
>such as the Widget::HTML::Template idea (milestone 5).  The two 
>might even complement each other.
>--
>James Smith <JG...@TA...>, 979-862-3725
>Texas A&M CIS Operating Systems Group, Unix
>
>_______________________________________________
>Perl-widget-developer mailing list
>Per...@li...
>http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>

Re: [Perl-widget-developer] thoughts on design

[Issac G. <ne...@wr...>]

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

----- Original Message -----
From: "Stephen Adkins" <ste...@of...>
To: <JG...@TA...>; <per...@li...>
Cc: <JG...@TA...>
Sent: Friday, June 01, 2001 16:50
Subject: Re: [Perl-widget-developer] thoughts on design


> James,
>
> Sounds like your thing is Themes.
> We want the Themes concept to work its way into the PWL.
> Please take a look at the software, Widget-0.01 found at
>
>    http://www.officevision.com/pub/Widget/
>
> Begin to understand the classes and the existing framework.
> Then start proposing on this list
>
>   1. a class or set of classes to implement Themes
>   2. XML configuration format to configure Themes
>
> When you understand how the PWL works and we all concur on
> how Themes fits in, you can go berzerk.
>
> Stephen
>
> At 10:53 PM 5/31/2001 -0500, James G Smith wrote:
> >Here are some thoughts and ideas I've had and played with in
> >various forms over the last few months regarding themeing and
> >html rendering.  Some things might be useful, some not.
> >
> >Background:  I am currently working on some PHP code to provide
> >an environment in which scripts can be independent from most
> >content which, in turn, can be independent of the look of the
> >page.  The theme object is called to render anything from form
> >input tags to tables.
> >
> >For a live example, browse https://neo.tamu.edu/xyzzy/ .  This is
> >a non-public alpha installation being used for current
> >development.  The Directory feature uses the theme object to
> >render the list of found records in LDAP as well as the actual
> >record itself.  You could think of the list as a list widget that
> >the theme object provides for the script.
> >
> >I am currently developing a table rendered in PHP that will
> >render using <pre>..</pre> text instead of tables.  This will
> >allow for a theme that uses no tables for those browsers that
> >have a hard time rendering tables.
> >
> >In addition to providing some components/widgets for the scripts,
> >the theme object also handles the page layout.  At the moment, I
> >have enumerated 47 (16 with all edge content intact + 31 with
> >some edge component missing) different ways to layout a page with
> >central and edge content.  For example, the default look of the
> >above development site is as follows:
> >
> >+---------+
> >|   Top   |
> >+---------+
> >|         |
> >| Content |
> >|         |
> >+---------+
> >|  Bottom |
> >+---------+
> >
> >I don't have the proper data structure initialized for this
> >particular layout, but if I did, the user would have the choice
> >of having this rendered using frames or tables.  Currently, it
> >will only use tables.  This is done without the script or theme's
> >knowledge.
> >
> >http://hex.tamu.edu/test.php has three themes available for
> >demostration.  It also shows what the ldap directory object
> >returns from a successful lookup (me).
> >
> >Back to the Present:  I would like to bring as much of this logic
> >as possible over into the Perl world.  I think a widget system
> >would be a good way to do it.  A theme could possibly be a widget
> >factory -- I ask it for a widget that can draw a table, and it
> >gives me one.  I don't have to know what the package is or the
> >specifics of configuring it, as long as I can give it a set of
> >headers and the table contents and it can draw a table for me.
> >
> >I could give the theme object back a set of widgets and it could
> >render the page, allowing for the user to choose frames or no
> >frames (for example) without causing drastic problems in the code
> >composing the page.  Perhaps this could be done with the template
> >idea....
> >
> >Widgets could still be used outside of the widget factory, but
> >the code would need to know which widget it was using.  The
> >factory would need to be aware of all the types of widgets being
> >used in the site.  It could also handle the burden of doing the
> >general configuration of widgets, allowing the scripts to focus
> >on the items that make the widget unique/useful in their context.
> >
> >This could also be done (I think) parallel with other efforts
> >such as the Widget::HTML::Template idea (milestone 5).  The two
> >might even complement each other.
> >--
> >James Smith <JG...@TA...>, 979-862-3725
> >Texas A&M CIS Operating Systems Group, Unix
> >
> >_______________________________________________
> >Perl-widget-developer mailing list
> >Per...@li...
> >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
> >
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>

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

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

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

I agree with this plan.

At 11:37 PM 6/2/2001 -0400, Stephen Adkins wrote:
>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
>
>
>
>
>
>
>_______________________________________________
>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/

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

[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