[Perl-widget-developer] Handling JavaScript and Events

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

At 10:59 PM 6/3/01 -0400, Stephen Adkins wrote:
>At 08:47 AM 6/4/2001 +0800, Gunther Birznieks wrote:
> >At 05:53 PM 6/3/01 -0400, Stephen Adkins wrote:
>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.

The hard pieces of this I think this can be handled quite easily because 
you have a controller.

You need a widget to be a javascript generator. Each javascript routine is 
a widget/component.

Then you configure a widget that requires a javascript routine to have that 
javascript subroutine widget inside of itself and tell it to tell the 
controller to please look for a special widget that understand how to 
accept javascript widgets and then hand all of the javascript subroutine 
widgets to the main one. The main javascript widget that you place at the 
top of the page would then take all the javascript routines and make sure 
they do not repeat and all that kind of stuff and would be responsible for 
printing the script header and footer.

To handle the events in Perl is a tougher one. My feeling is that this was 
going to be handled within a widget anyway. eg based on the state of CGI.pm 
saying that the up arrow was pressed, then rearrange how the listbox is 
generated.

If these are separate widgets, I think it can still be done, but you don't 
need an event mechanism. You can use the same mechansim of the small 
javascript widgets being encapsulated in a larger one. These widgets of 
course have to be built to know about each other because they are connected 
widgets. Normal HTML widgets would not know about each other. These are the 
simple widgets with the simple interface.

It's when you build up these complex ones that you are allowed to add your 
arbitrary interfaces. the ones that need to be most settled on (just to 
have a standard) are the way in which JavaScript is passed to the main 
JavaScript subroutine header widget I think.

I don't believe that the abstraction for events should be events. I think 
it would be much easier to create an up arrow widget that detects when it's 
pressed through a CGI.pm value.

Then upon doing so, it should feel free to take another widget (b4 being 
rendered) and then call a method to manipulate the values in it and how it 
should be displayed.

So an HTML listbox widget could very well have a method that is specific to 
listboxes to say moveAllSelectedItemsUpOneLevel(). Then your only CUSTOM 
widget is your up arrow one where you manually code a routine that checks 
if the widget was clicked and if so, look for a widget of a specific name 
and call it's moveAllSelectedItemsUpOneLevel() routine.

This is flexible and keeps the core HTML widgets simple while moving the 
complexity of handling the event stuff with the code for the up arrow.