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

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

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