perl-widget-developer Mailing List for Perl Widget Library (Page 10)
Status: Alpha
Brought to you by:
spadkins
Menu
▾
▴
perl-widget-developer — Discussion about bugs and further development of Perl Widgets
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(132) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(6) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(9) |
| 2007 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(19) |
Sep
(6) |
Oct
(5) |
Nov
(5) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(7) |
Mar
(34) |
Apr
(13) |
May
(15) |
Jun
(5) |
Jul
(14) |
Aug
(6) |
Sep
(6) |
Oct
(3) |
Nov
(1) |
Dec
|
|
From: Stephen A. <ste...@of...> - 2001-06-04 22:19:40
|
Issac, There are two statements here. It seems you object to the second. What about the first statement? Do you agree that that is what we are building? With regard to your response to the second statement... Do you *really* care about any of those other environments? Do you build X applications? Curses application? I build web applications. But I hate the request/response model of programming. The reason I care about the other technical environments is that I believe that considering them will help my efforts at abstraction. Programming widgets in X is on an event-driven programming model, and I want that same programming model for the web. Stephen At 09:36 PM 6/4/2001 +0200, Issac Goldstand wrote: >Nope. I'd say we're making a GENERIC set of controls - we just happen to be >focusing on HTML for our first step - but we shouldn't do things the "easy" >way (if/when it's all that HTML requires) just because we happen to be >focusing on HTML just now - we should put in significant effort to leave it >open. > > Issac > >----- Original Message ----- >From: "Stephen Adkins" <ste...@of...> >To: <per...@li...> >Sent: Monday, June 04, 2001 06:36 >Subject: [Perl-widget-developer] Team-building question of the day > > >> Hi, >> >> I would appreciate a high response rate on this question from members >> of the list who expect to contribute any opinions or code in the coming >> month. (i.e. *not* silent list members) >> >> * Do you agree with the following two statements? >> >> 1. Perl Widget Library is a library of useful HTML user interface widgets, >> and a framework for extending them and developing your own. >> >> 2. The library is designed conceptually to support non-HTML widgets too, >> such as WML, Gtk/X, Curses, but we'll only get to those if it doesn't >> compromise our ability to make HTML widgets. >> >> Stephen >> >> >> _______________________________________________ >> Perl-widget-developer mailing list >> Per...@li... >> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer >> > > |
|
From: Issac G. <ne...@wr...> - 2001-06-04 21:51:53
|
> Issac, > > There are two statements here. > It seems you object to the second. > What about the first statement? Do you agree that that is what we are > building? At the offset - absolutely. Although I think we're building a generic system, I agree that our first order is designing this to work in an HTML environment. > With regard to your response to the second statement... > Do you *really* care about any of those other environments? > Do you build X applications? Curses application? Actually, no I don't - but that doesn't mean that I don't realize that other potential _users_ do - remember, as with any kind of product, your wants are only secondary - it's the thoughts of the users (be them developers using tools, or end-users using software) that count the most... I'm not saying that we have to build these modules right now (or even EVER). What I am saying is that I believe that we are able to - and therefore, as programmers developing a good "development tool" should - build the options for future interoperability into the system as much as we can. > I build web applications. > But I hate the request/response model of programming. We have a request/response environment too: HTTP > The reason I care about the other technical environments is that I believe > that considering them will help my efforts at abstraction. Programming > widgets in X is on an event-driven programming model, and I want that same > programming model for the web. OK - So I'll agree that it mght take considerable abstraction and thought into figuring out how to converge the different schemes that we'd LIKE to support future interoperability with into a single abstract set of base classes. So it'll mean a bit of extra thinking and arguaing about future implementations on this list now - so? We can deal with it, I think. And better now, while we're in a good position to work it out, than later when implementing changes like this will cause major compatibility problems... Issac > Stephen > > > At 09:36 PM 6/4/2001 +0200, Issac Goldstand wrote: > >Nope. I'd say we're making a GENERIC set of controls - we just happen to be > >focusing on HTML for our first step - but we shouldn't do things the "easy" > >way (if/when it's all that HTML requires) just because we happen to be > >focusing on HTML just now - we should put in significant effort to leave it > >open. > > > > Issac > > > >----- Original Message ----- > >From: "Stephen Adkins" <ste...@of...> > >To: <per...@li...> > >Sent: Monday, June 04, 2001 06:36 > >Subject: [Perl-widget-developer] Team-building question of the day > > > > > >> Hi, > >> > >> I would appreciate a high response rate on this question from members > >> of the list who expect to contribute any opinions or code in the coming > >> month. (i.e. *not* silent list members) > >> > >> * Do you agree with the following two statements? > >> > >> 1. Perl Widget Library is a library of useful HTML user interface widgets, > >> and a framework for extending them and developing your own. > >> > >> 2. The library is designed conceptually to support non-HTML widgets too, > >> such as WML, Gtk/X, Curses, but we'll only get to those if it doesn't > >> compromise our ability to make HTML widgets. > >> > >> Stephen > >> > >> > >> _______________________________________________ > >> Perl-widget-developer mailing list > >> Per...@li... > >> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer > >> > > > > > |
|
From: Issac G. <ne...@wr...> - 2001-06-04 21:36:29
|
Nope. I'd say we're making a GENERIC set of controls - we just happen to be focusing on HTML for our first step - but we shouldn't do things the "easy" way (if/when it's all that HTML requires) just because we happen to be focusing on HTML just now - we should put in significant effort to leave it open. Issac ----- Original Message ----- From: "Stephen Adkins" <ste...@of...> To: <per...@li...> Sent: Monday, June 04, 2001 06:36 Subject: [Perl-widget-developer] Team-building question of the day > Hi, > > I would appreciate a high response rate on this question from members > of the list who expect to contribute any opinions or code in the coming > month. (i.e. *not* silent list members) > > * Do you agree with the following two statements? > > 1. Perl Widget Library is a library of useful HTML user interface widgets, > and a framework for extending them and developing your own. > > 2. The library is designed conceptually to support non-HTML widgets too, > such as WML, Gtk/X, Curses, but we'll only get to those if it doesn't > compromise our ability to make HTML widgets. > > Stephen > > > _______________________________________________ > Perl-widget-developer mailing list > Per...@li... > http://lists.sourceforge.net/lists/listinfo/perl-widget-developer > |
|
From: Stephen A. <ste...@of...> - 2001-06-04 13:56:41
|
FYI, You can see the Perl Widget Library in action at (prepare to be underwhelmed) http://www.officevision.com/cgi-bin/pub/Widget/cgisample Of course, it's not very exciting yet. The file cgi-bin/cgisample is a part of the distribution. It is in CVS. Stephen |
|
From: James G S. <JG...@TA...> - 2001-06-04 09:00:56
|
Stephen Adkins <ste...@of...> wrote: >1. Perl Widget Library is a library of useful HTML user interface widgets, >and a framework for extending them and developing your own. To a large degree, yes. I think it can be used for more than just HTML output when building a page. Session management comes to mind. >2. The library is designed conceptually to support non-HTML widgets too, >such as WML, Gtk/X, Curses, but we'll only get to those if it doesn't >compromise our ability to make HTML widgets. I don't see why it can't be used to build a forms-based application in any user-interface system. That's basically what a browser is without client-side scripting. We just need to be careful that we write the library in such a way that only initialization needs to be changed when moving to a different rendering environment (or try for that as much as possible). This allows for complex widgets to be build on simpler ones with only the simpler ones needing to be eventually aware of the details of the rendering. -- James Smith <JG...@TA...>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix |
|
From: Stephen A. <ste...@of...> - 2001-06-04 06:38:03
|
Hi,
Thanks for the prodding, Cees and Gunther.
I made the following changes today.
* added named parameters to allow things like
Widget->controller(-cgi => $cgi) ... and ...
$wc->widget(-name => "birth_dt", -maxlength => 18)
If "maxlength" is not used in the production of the widget, it
is ignored. This overrides any values that may be in the config
file. Note that non-named params are also supported ...
$wc->widget("birth_dt") but the positions must be well-known
(not yet documented) ;-)
* added widget overrides (as shown above)
These changes are in CVS, and a Widget-0.02.tar.gz release is made
available on the home page.
I will work on simple Perl config soon and implement a handful of
other simple widgets. This release (0.03?) will be ready for
torture-testing by Gunther and enumeration of items in order to
achieve Milestone 3.
Stephen
|
|
From: Stephen A. <ste...@of...> - 2001-06-04 04:43:39
|
Hi, I would appreciate a high response rate on this question from members of the list who expect to contribute any opinions or code in the coming month. (i.e. *not* silent list members) * Do you agree with the following two statements? 1. Perl Widget Library is a library of useful HTML user interface widgets, and a framework for extending them and developing your own. 2. The library is designed conceptually to support non-HTML widgets too, such as WML, Gtk/X, Curses, but we'll only get to those if it doesn't compromise our ability to make HTML widgets. Stephen |
|
From: Stephen A. <ste...@of...> - 2001-06-04 03:04:14
|
At 08:47 AM 6/4/2001 +0800, Gunther Birznieks wrote: >At 05:53 PM 6/3/01 -0400, Stephen Adkins wrote: ... >>Per Gunther, I considered CGI::Util::rearrange(), and opted for the >>rule: "when first char of first arg is dash (-), use named args". >>We may go to rearrange(), but it seems like a lot of overhead that we >>don't need. (CGI.pm had a huge installed base using an old syntax to >>support.) > >Just a bit of history. The BioPerl initiative also had a similar discussion >of what to do about named parameters. In the end, they ended up using a >CGI.pm style with a slightly differently written rearrange method. Of >course it is no coincidence that Lincoln Stein was part of BioPerl (loosely). > >As I recall, the biggest deal is that you really need to stick with the >convention of the preceding - for named params. The reason for this is to >make it convenient not to have to quote them. When you allow for just >simple names, then it's possible for those names to conflict with existing >subroutine names. Before accepting them as a strings, Perl attempts to >resolve unquoted values as constants (which are really subroutines). > >I have to ask... what is the meaning behind your statement "rearrange is a >lot of overhead to go with"... > >Does that mean you are doing what rearrange does but in-line within the >constructor? Yes. And they have a data-driven scheme for generalizing which parameters are intended positionally, and it just seems to be a bit of processing just to get the parameters in place. I just inlined a simpler algorithm. ... >> >In the first release, the Widgets were conpletely driven by hte Config >> >object. I have added some support that allows the widgets to be >> >configured at initialization time as well as from the Config object. >> >This allows someone to create a Widget as such: >> > >> > $widget = $wc->widget( >> > -name => 'category', >> > -class => 'Widget::HTML::Select', >> > -values => ['Foo', 'Bar'], >> > ); >> >>I knew people would want to do this, and I have been working on adding >>it myself. However, I consider this usage the "low road". It encourages >>people to do exactly what the library is supposed to get them away from ... >>caring about the details of the widget. It also inhibits the configurer >>from snapping a new implementation of a widget in to upgrade the page. >> >>However, this is "simpler" and I expect that we will have "high road" >>users (using the library more ideally) and "low road" users (employing >>short cuts which somewhat short-change the real value of the library). >> >>Actually this philosophy is in keeping with Perl. ;-) >>There's more than one way to do it. > >I don't understand precisely how you think the above code lends itself to >not being configurable? As long as the parameters are a simple list, then >in the main config of a CGI script, I can say > >@CATEGORY_WIDGET = (-name => 'category' etc...); > >And then within the code.... > >$widget = new Widget(@CATEGORY_WIDGET) > >type of thing. Or within a custom controller. > This is a bigger topic. I think it runs to the core of the <bigger> vision I have for widgets vs. the <lesser> vision that I am trying to satisfy immediately for you. The lesser vision is to splash some HTML up in the correct place. The bigger vision is to create active widgets whose processing across multiple requests should be handled internally to the widget library and which should almost not even be noticed by the application code. (Uh oh. I said it was a bigger topic, and here I am getting into it.) Take, for example, a reorderable multi-select list. Imagine the car type list selection control implemented at http://demo:de...@ww.../cgi-bin/prod/members/mv/MarketVision It is actually many items, but one logical widget. * a <select multiple> for the "non-selected" car types, * a <select multiple> for the "selected" car types, * a "select" (right arrow) image button, * an "unselect" (left arrow) image button, * an "UP" (up arrow) image button, * a "DOWN" (down arrow) image button, * an <input type=hidden> variable containing the "selected" list of car types * a bunch of Javascript needing inclusion at the top of the page * a bunch of Perl code to handle the events if Javascript is disabled Let us suppose that Javascript is not being used. Each button press makes a round trip to the server and back, but the application logic should not be engaged. In essence, this was an "event" completely internal to the PWL. If key values of a widget (i.e. the class) are only known at rendering time rather than through a config file separate from the widget ever being rendered, the library will not know how to process the event. It is this type of processing that requires the PWL to know the attributes of a widget even if it has not been asked to be rendered. OK. That's all for now. I'll come back to this point later. I need to finish some coding. Stephen |
|
From: Gunther B. <gu...@ex...> - 2001-06-04 01:13:26
|
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'>\<</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'>\></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
|
|
From: Gunther B. <gu...@ex...> - 2001-06-04 01:10:07
|
At 05:53 PM 6/3/01 -0400, Stephen Adkins wrote:
>Cees,
>
>1. I am encouraged that someone is looking at the code.
> Good for you Cees.
>2. Your suggestions are good, but your patches conflict with things
> that I am working on. I understand that it was worth it to you
> just to play with the code.
>
>See below for comments.
>
>Stephen
>
>At 10:30 PM 6/2/2001 -0500, ce...@si... wrote:
>...
> >First off, any options we pass to a constructor should probably be in a
> >hash, so the user doesn't have to worry about order of variables:
> >
> >$anniv_dt = $wc->widget(-name => "anniv_dt");
> >instead of
> >$anniv_dt = $wc->widget("anniv_dt");
> >
>
>Good idea, but I don't like being forced to use named parameters for
>everything when a single parameter (i.e. $name) is what is almost always
>expected.
>
>Per Gunther, I considered CGI::Util::rearrange(), and opted for the
>rule: "when first char of first arg is dash (-), use named args".
>We may go to rearrange(), but it seems like a lot of overhead that we
>don't need. (CGI.pm had a huge installed base using an old syntax to
>support.)
Just a bit of history. The BioPerl initiative also had a similar discussion
of what to do about named parameters. In the end, they ended up using a
CGI.pm style with a slightly differently written rearrange method. Of
course it is no coincidence that Lincoln Stein was part of BioPerl (loosely).
As I recall, the biggest deal is that you really need to stick with the
convention of the preceding - for named params. The reason for this is to
make it convenient not to have to quote them. When you allow for just
simple names, then it's possible for those names to conflict with existing
subroutine names. Before accepting them as a strings, Perl attempts to
resolve unquoted values as constants (which are really subroutines).
I have to ask... what is the meaning behind your statement "rearrange is a
lot of overhead to go with"...
Does that mean you are doing what rearrange does but in-line within the
constructor?
It's also possible that you might want to use rearrange just for the
constructor. It may be theoretically slower but you get stronger typing,
and in a mod_perl universe where you may have many widgets, the overhead
should theoretically only occur when the widgets are constructed.
Hopefully, a mod_perl programmer would cache the widget controllers for
subsequent requests.
> >In the first release, the Widgets were conpletely driven by hte Config
> >object. I have added some support that allows the widgets to be
> >configured at initialization time as well as from the Config object.
> >This allows someone to create a Widget as such:
> >
> > $widget = $wc->widget(
> > -name => 'category',
> > -class => 'Widget::HTML::Select',
> > -values => ['Foo', 'Bar'],
> > );
>
>I knew people would want to do this, and I have been working on adding
>it myself. However, I consider this usage the "low road". It encourages
>people to do exactly what the library is supposed to get them away from ...
>caring about the details of the widget. It also inhibits the configurer
>from snapping a new implementation of a widget in to upgrade the page.
>
>However, this is "simpler" and I expect that we will have "high road"
>users (using the library more ideally) and "low road" users (employing
>short cuts which somewhat short-change the real value of the library).
>
>Actually this philosophy is in keeping with Perl. ;-)
>There's more than one way to do it.
I don't understand precisely how you think the above code lends itself to
not being configurable? As long as the parameters are a simple list, then
in the main config of a CGI script, I can say
@CATEGORY_WIDGET = (-name => 'category' etc...);
And then within the code....
$widget = new Widget(@CATEGORY_WIDGET)
type of thing. Or within a custom controller.
>I have added you as a developer (CVS write access).
>However, please do not assume your changes will not conflict without
>discussing it first on the mailing list.
>And do not commit anything without first getting an OK on the mailing list.
Well small bug fixes are easily but the code seems so small right now that
any major change will cause a CVS conflict upon merge. So this seems
reasonable for now.
Later,
Gunther
|
|
From: Stephen A. <ste...@of...> - 2001-06-03 23:22:29
|
Cees,
1. I am encouraged that someone is looking at the code.
Good for you Cees.
2. Your suggestions are good, but your patches conflict with things
that I am working on. I understand that it was worth it to you
just to play with the code.
See below for comments.
Stephen
At 10:30 PM 6/2/2001 -0500, ce...@si... wrote:
...
>First off, any options we pass to a constructor should probably be in a
>hash, so the user doesn't have to worry about order of variables:
>
>$anniv_dt = $wc->widget(-name => "anniv_dt");
>instead of
>$anniv_dt = $wc->widget("anniv_dt");
>
Good idea, but I don't like being forced to use named parameters for
everything when a single parameter (i.e. $name) is what is almost always
expected.
Per Gunther, I considered CGI::Util::rearrange(), and opted for the
rule: "when first char of first arg is dash (-), use named args".
We may go to rearrange(), but it seems like a lot of overhead that we
don't need. (CGI.pm had a huge installed base using an old syntax to
support.)
>I noticed this morning that someone had patched the Controller Classes to
>accept a hashref in the constructor, however, I think this should be a
>hash instead of a hashref (for simplicity of the interface).
>
>$wc = Widget->controller({cgi => $query});
>Should become
>$wc = Widget->controller(cgi => $query);
Yeah. I agree.
>In the first release, the Widgets were conpletely driven by hte Config
>object. I have added some support that allows the widgets to be
>configured at initialization time as well as from the Config object.
>This allows someone to create a Widget as such:
>
> $widget = $wc->widget(
> -name => 'category',
> -class => 'Widget::HTML::Select',
> -values => ['Foo', 'Bar'],
> );
I knew people would want to do this, and I have been working on adding
it myself. However, I consider this usage the "low road". It encourages
people to do exactly what the library is supposed to get them away from ...
caring about the details of the widget. It also inhibits the configurer
from snapping a new implementation of a widget in to upgrade the page.
However, this is "simpler" and I expect that we will have "high road"
users (using the library more ideally) and "low road" users (employing
short cuts which somewhat short-change the real value of the library).
Actually this philosophy is in keeping with Perl. ;-)
There's more than one way to do it.
>This change to allow widgets to be defined dynamically has another
>implication. In the first release, none of the widgets did much at
>initialization time. They did not read the config file until a rendering
>function was called (ie ->html()). If we are passing config info through
>the constructor, then all this initialization will have to be done in the
>constructor.
>This will greatly simplify the html() function, but make the init()
>function more complex.
>
>I have also gone ahead and redesigned the DateDropDowns.pm to use the
>child/parent structure. When DateDropDowns is initialized, it creates 3
>new widgets and stores them in the object. These widgets are not listed
>in the Config file, since DateDropDowns should know how to configure them
>automatically:
>
> $self->{year} = $self->{controller}->widget(
> -name => $self->{name}.'.year',
> -class => 'Widget::HTML::Select',
> -controller => $self->{controller},
> -parent => $self,
> -values => [$start_year..$end_year],
> );
> $self->{month} = ...
> $self->{day} = ...
>
>and I added three helper function that will allow the user to access these
>widgets directly. This allows someone to do the following:
>
>$anniv_dt = $wc->widget(-name => "anniv_dt");
>$anniv_dt->value(); # Something like yyyy-mm-dd
>$anniv_dt->year->value(); # just returns or sets the year part
>
>I also noticed a small bug in Widget/Base.pm with the value() function
>(The @_ was no longer being sent to the state->value function.
I found this too.
>sub value {
> my $self = shift;
> my $value = $self->{controller}->state()->value($self->{name}, @_);
> ^^^^
>}
>
>The @_ was missing, and should be included if someone wants to set the
>value of the widget.
>
>I have included a patch file that will implement the above changes. I
>hope they don't conflict with anyone elses changes. I understand that I
>should have discussed what I was working on before implementing these
>changes, but this was a good way for me to learn the code, and see where
>it could use improvements.
Sorry, but I can't use the patch files because of conflicts.
I did look at them.
>If this patch file is too big, or conflicts with other changes, I don't
>mind breaking it up, or redoing it. I have a sourceforge account
>(ceeshek), but I don't know if you want to give everyone CVS access or
>not... If not, I will continue to send patches, otherwise, I will discuss
>my changes on the list, and patch the tree myself.
I have added you as a developer (CVS write access).
However, please do not assume your changes will not conflict without
discussing it first on the mailing list.
And do not commit anything without first getting an OK on the mailing list.
>Also, please note that I am working from Sydney Australia, so my messages
>to the list may come at strange hours :)
>
>I think this project has had a very positive start, and I am looking
>forward to seeing it develop into an easy, yet powerful tool.
>
>Cees Hek
>
Thanks.
Stephen
|
|
From: Issac G. <ne...@wr...> - 2001-06-03 19:14:30
|
OK - Before you all bite, I'm going to mention that I'm making a = suggestion for future compatibility here... But with XML getting = stronger each day, it might be a wise idea if we kept it in mind, at the = very least, while developing our widgets... I can see some very nice = uses for widgets which can bind to XML data - and of course, by using = XSL (or anything else - I used XSL as an example simply because it's a = W3C Recommendation) we can bind XML elements to any output form... Once again, I don't think we should jump into it right now, but I think = that it should be put on our list of things o do shortly after HTML and = WML... Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B |
|
From: Issac G. <ne...@wr...> - 2001-06-03 18:50:33
|
I'll second "render"... Issac ----- Original Message ----- From: "Gunther Birznieks" <gu...@ex...> To: <Per...@li...> Sent: Sunday, June 03, 2001 17:38 Subject: [Perl-widget-developer] Widget display/html output method name > At 02:17 PM 6/3/01 +0200, Issac Goldstand wrote: > > > > > 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 :) > > > > > > >How about activate() or something else that can generically describe the > >Widget... Theoretically, we could creaate a Timer widget (that does some > >event after a certain time elaplses). In such a case, words like "display" > >"draw" or "render" don't make sense... Of course, we're not really > >"activating" the widgets either, as we're creating them on-the-fly in the > >target environment (e.g., HTML), but my personal hilosophy when designing > >"thing"s to be used by developers is to try to pick names for methods and > >properties that are easy to understand and _make sense_... They'll > >appreciate it. > > I agree that display, draw or render seems quite active as if to imply > print. But these are fairly standard (especially draw) in GUI systems. The > fact that a component is draw() was called doesn't actually mean it is > displayed. In some cases, the draw can be just placed on a backend bitmap > which will never display (double buffering). > > I dislike the name draw because it has a connotation of raw bitmaps (like > drawing programs). > > By far, the best method name I have seen is render. It is semantically > accurate. The widget is being rendered but it's not being displayed. > > Activate is one that I dislike because it implies you do it once or implies > a state change (active/inactive). This is not true. There is a distinct > value being returned when render() would be called. > > Later, > Gunther > > > _______________________________________________ > Perl-widget-developer mailing list > Per...@li... > http://lists.sourceforge.net/lists/listinfo/perl-widget-developer > |
|
From: Jay L. <Ja...@La...> - 2001-06-03 15:55:10
|
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'>\<</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'>\></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 |
|
From: Gunther B. <gu...@ex...> - 2001-06-03 15:38:07
|
At 02:17 PM 6/3/01 +0200, Issac Goldstand wrote:
> > 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 :)
> >
>
>How about activate() or something else that can generically describe the
>Widget... Theoretically, we could creaate a Timer widget (that does some
>event after a certain time elaplses). In such a case, words like "display"
>"draw" or "render" don't make sense... Of course, we're not really
>"activating" the widgets either, as we're creating them on-the-fly in the
>target environment (e.g., HTML), but my personal hilosophy when designing
>"thing"s to be used by developers is to try to pick names for methods and
>properties that are easy to understand and _make sense_... They'll
>appreciate it.
I agree that display, draw or render seems quite active as if to imply
print. But these are fairly standard (especially draw) in GUI systems. The
fact that a component is draw() was called doesn't actually mean it is
displayed. In some cases, the draw can be just placed on a backend bitmap
which will never display (double buffering).
I dislike the name draw because it has a connotation of raw bitmaps (like
drawing programs).
By far, the best method name I have seen is render. It is semantically
accurate. The widget is being rendered but it's not being displayed.
Activate is one that I dislike because it implies you do it once or implies
a state change (active/inactive). This is not true. There is a distinct
value being returned when render() would be called.
Later,
Gunther
|
|
From: Issac G. <ne...@wr...> - 2001-06-03 11:39:11
|
> 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 :) > How about activate() or something else that can generically describe the Widget... Theoretically, we could creaate a Timer widget (that does some event after a certain time elaplses). In such a case, words like "display" "draw" or "render" don't make sense... Of course, we're not really "activating" the widgets either, as we're creating them on-the-fly in the target environment (e.g., HTML), but my personal hilosophy when designing "thing"s to be used by developers is to try to pick names for methods and properties that are easy to understand and _make sense_... They'll appreciate it. Issac |
|
From: <ce...@si...> - 2001-06-03 08:08:57
|
> 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 |
|
From: Gunther B. <gu...@ex...> - 2001-06-03 07:08:07
|
At 10:30 PM 6/2/2001 -0500, ce...@si... wrote:
>I have a few comments on the design of the code base. I have really only
>focussed on the Widget side of things and haven't really looked into the
>Controller/State/Config stuff too closely. Also, I learn by playing with
>the code, so I have included a patch file of my suggested changes that I
>discuss below.
>
>First off, any options we pass to a constructor should probably be in a
>hash, so the user doesn't have to worry about order of variables:
>
>$anniv_dt = $wc->widget(-name => "anniv_dt");
>instead of
>$anniv_dt = $wc->widget("anniv_dt");
>
>I noticed this morning that someone had patched the Controller Classes to
>accept a hashref in the constructor, however, I think this should be a
>hash instead of a hashref (for simplicity of the interface).
>
>$wc = Widget->controller({cgi => $query});
>Should become
>$wc = Widget->controller(cgi => $query);
>
>In the first release, the Widgets were conpletely driven by hte Config
>object. I have added some support that allows the widgets to be
>configured at initialization time as well as from the Config object.
>This allows someone to create a Widget as such:
>
> $widget = $wc->widget(
> -name => 'category',
> -class => 'Widget::HTML::Select',
> -values => ['Foo', 'Bar'],
> );
I like the familiar _rearrange() method that CGI.pm uses. I think it's
simple and supports all the ways people tend to want to use methods.
>This change to allow widgets to be defined dynamically has another
>implication. In the first release, none of the widgets did much at
>initialization time. They did not read the config file until a rendering
>function was called (ie ->html()). If we are passing config info through
>the constructor, then all this initialization will have to be done in the
>constructor.
>
>This will greatly simplify the html() function, but make the init()
>function more complex.
From a design pattern perspective, I have to say that this is better
design. Constructions and Configuration methods (init) should by nature be
more complex than the methods that perform operations.
This is entirely necessary so that the method signature for performing
actions can remain the same throughout the code and only the part at the
start of the code (which determines how the object is constructed) is changed.
Think of DBD drivers as an example. Each one accepts different connect()
arguments but for the most part you can assume (other than SQL differences)
that the methods remain the same.
>I have also gone ahead and redesigned the DateDropDowns.pm to use the
>child/parent structure. When DateDropDowns is initialized, it creates 3
>new widgets and stores them in the object. These widgets are not listed
>in the Config file, since DateDropDowns should know how to configure them
>automatically:
>
> $self->{year} = $self->{controller}->widget(
> -name => $self->{name}.'.year',
> -class => 'Widget::HTML::Select',
> -controller => $self->{controller},
> -parent => $self,
> -values => [$start_year..$end_year],
> );
> $self->{month} = ...
> $self->{day} = ...
>
>and I added three helper function that will allow the user to access these
>widgets directly. This allows someone to do the following:
>
>$anniv_dt = $wc->widget(-name => "anniv_dt");
>$anniv_dt->value(); # Something like yyyy-mm-dd
>$anniv_dt->year->value(); # just returns or sets the year part
I think this is reasonable.
>I also noticed a small bug in Widget/Base.pm with the value() function
>(The @_ was no longer being sent to the state->value function.
>Also, this function should probably trigger a 'change' event if the value
>is being changed.
>
>sub value {
> my $self = shift;
> my $value = $self->{controller}->state()->value($self->{name}, @_);
> ^^^^
>}
>
>The @_ was missing, and should be included if someone wants to set the
>value of the widget.
>
>I have included a patch file that will implement the above changes. I
>hope they don't conflict with anyone elses changes. I understand that I
>should have discussed what I was working on before implementing these
>changes, but this was a good way for me to learn the code, and see where
>it could use improvements.
>
>If this patch file is too big, or conflicts with other changes, I don't
>mind breaking it up, or redoing it. I have a sourceforge account
>(ceeshek), but I don't know if you want to give everyone CVS access or
>not... If not, I will continue to send patches, otherwise, I will discuss
>my changes on the list, and patch the tree myself.
>
In principle I personally like the changes.
>Also, please note that I am working from Sydney Australia, so my messages
>to the list may come at strange hours :)
Not that strange of a timezone for me.
We started our open source company in Singapore last year. Exactly 12 hours
ahead of eastern standard time in the USA. :)
Later,
Gunther
|
|
From: Gunther B. <gu...@ex...> - 2001-06-03 06:55:11
|
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/ |
|
From: <ce...@si...> - 2001-06-03 03:55:40
Attachments:
patch1
|
I have a few comments on the design of the code base. I have really only
focussed on the Widget side of things and haven't really looked into the
Controller/State/Config stuff too closely. Also, I learn by playing with
the code, so I have included a patch file of my suggested changes that I
discuss below.
First off, any options we pass to a constructor should probably be in a
hash, so the user doesn't have to worry about order of variables:
$anniv_dt = $wc->widget(-name => "anniv_dt");
instead of
$anniv_dt = $wc->widget("anniv_dt");
I noticed this morning that someone had patched the Controller Classes to
accept a hashref in the constructor, however, I think this should be a
hash instead of a hashref (for simplicity of the interface).
$wc = Widget->controller({cgi => $query});
Should become
$wc = Widget->controller(cgi => $query);
In the first release, the Widgets were conpletely driven by hte Config
object. I have added some support that allows the widgets to be
configured at initialization time as well as from the Config object.
This allows someone to create a Widget as such:
$widget = $wc->widget(
-name => 'category',
-class => 'Widget::HTML::Select',
-values => ['Foo', 'Bar'],
);
This change to allow widgets to be defined dynamically has another
implication. In the first release, none of the widgets did much at
initialization time. They did not read the config file until a rendering
function was called (ie ->html()). If we are passing config info through
the constructor, then all this initialization will have to be done in the
constructor.
This will greatly simplify the html() function, but make the init()
function more complex.
I have also gone ahead and redesigned the DateDropDowns.pm to use the
child/parent structure. When DateDropDowns is initialized, it creates 3
new widgets and stores them in the object. These widgets are not listed
in the Config file, since DateDropDowns should know how to configure them
automatically:
$self->{year} = $self->{controller}->widget(
-name => $self->{name}.'.year',
-class => 'Widget::HTML::Select',
-controller => $self->{controller},
-parent => $self,
-values => [$start_year..$end_year],
);
$self->{month} = ...
$self->{day} = ...
and I added three helper function that will allow the user to access these
widgets directly. This allows someone to do the following:
$anniv_dt = $wc->widget(-name => "anniv_dt");
$anniv_dt->value(); # Something like yyyy-mm-dd
$anniv_dt->year->value(); # just returns or sets the year part
I also noticed a small bug in Widget/Base.pm with the value() function
(The @_ was no longer being sent to the state->value function.
Also, this function should probably trigger a 'change' event if the value
is being changed.
sub value {
my $self = shift;
my $value = $self->{controller}->state()->value($self->{name}, @_);
^^^^
}
The @_ was missing, and should be included if someone wants to set the
value of the widget.
I have included a patch file that will implement the above changes. I
hope they don't conflict with anyone elses changes. I understand that I
should have discussed what I was working on before implementing these
changes, but this was a good way for me to learn the code, and see where
it could use improvements.
If this patch file is too big, or conflicts with other changes, I don't
mind breaking it up, or redoing it. I have a sourceforge account
(ceeshek), but I don't know if you want to give everyone CVS access or
not... If not, I will continue to send patches, otherwise, I will discuss
my changes on the list, and patch the tree myself.
Also, please note that I am working from Sydney Australia, so my messages
to the list may come at strange hours :)
I think this project has had a very positive start, and I am looking
forward to seeing it develop into an easy, yet powerful tool.
Cees Hek
|
|
From: Stephen A. <ste...@of...> - 2001-06-03 03:39:52
|
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
|
|
From: Issac G. <ne...@wr...> - 2001-06-02 19:22:30
|
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 > |
|
From: Stephen A. <ste...@of...> - 2001-06-01 22:01:28
|
Hi, I have significantly upgraded the home page for the Perl Widget Library. It tries to better explain "what it is" and "why we are doing this". http://www.officevision.com/pub/Widget/ I would encourage everyone to read and discuss this. It is incredible how even a small group of developers can disagree about a Widget library! ;-) Stephen P.S. For major issues, let's please only have one major issue per email. That way, we can track the discussion in the mailing list archive (as opposed to the nightmare "Real Widgets and Template Languages" thread on modperl). |
|
From: Stephen A. <ste...@of...> - 2001-06-01 14:44:38
|
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 > |
|
From: James G S. <JG...@TA...> - 2001-06-01 03:51:19
|
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 |
56 messages has been excluded from this view by a project administrator.
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X