Related to the previous discussion of closures vs object interface (eg
param) for getting CGI form data into the widgets:
While I think that it is clever to allow an interface to change where the
parameters come from, I think in practice there are different things to
expect. eg how to deal with multi-values? How to deal with file upload
field? I think there are quirks in various libraries.
I do not think these things are insurmountable. And Chip's suggestion
stands a good chance of working. I do also think there are so few libraries
to deal with parameters that it would not be an unreasonable design
decision to make the Widget controller hard code knowledge of CGI.pm,
Apache::Request and any others since there really aren't many.
At least at first cut. If it looks like there are too many data sources of
widget data to deal with then it has to be dealt with.
I would also offer the possibility that the data source for a widget should
not solely be a CGI.pm object but could conceivably come from many types of
data sources and that these data sources might have priorities yet all
apply to the same widget controller. Let's take a lesson (not necessarily
one to be followed) from PHP. In PHP, variables come into existence
automatically. But there are rules that are followed.
eg Cookies, Get,. Post which means that if the variable is somehow
resulting from a cookie instantiate the var as a the value of the cookie.
If there is a GET param of the same name, override the var with the value
of the Get param, and if there is a POST as well, then override the value
from $ENV{QUERY_STRING} with the value from the POST.
Likewise, we might consider that CGI.pm is the primary source of
information, but if I pass a db record set to the widget controller along
with CGI.pm, I may want CGI.pm to override the database but if there is no
CGI.pm value, then the value from the database field will be placed in the
widget instead.
Anyway, I am sorry if this sounds quite odd. I am not good at explaining
things when I am tired, but I did at least want to throw out the idea of
not being married yet to a particular way of having a widget consume data
from a data source.
