Gunther Birznieks <[EMAIL PROTECTED]> writes:
> 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.
Indeed, these are open questions that aren't dealt with so easily with
a closure. But I think for a general widget set, a closure would
work. If you want to get really tricky, you can bless the
closure... but at that point, you should just be using a class in the
first place.
> 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.
I disagree here; Mason, Apache::ASP, embperl, straight modperl,
CGI.pm, the various CGI accelerators, etc, are a variety of
interfaces. Anytime you have an application framework (or whatever
they're called this week), you can have a different interface to even
the simplest of things like form variables.
Another nice thing about not requiring CGI.pm or libapreq is you can
actually feed the formvars from something besides an HTTP submission
(useful for page generation into flat html, or for testing).
> 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.
I agree that there are a lot of various issues here for when it comes
to handling data input and output. But I think that for something
like a Widget set to be useful, it needs to be as decoupled as
possible from all external libraries, and still be able to play with
them. Now, that means one of two things.
(a) Some kind of base class (Some people suggest using an "implied"
interface without a true abstract base class that defines the various
methods; I am very much against this because it can lead to somewhat
sloppy programming. If you're going to use objects, use them in a way
that other languages tend to use them and not as typeless chunks that
respond to various kinds of black magic poking and prodding). I
personally only see this being not-the-best-option because of
unnecessary complexity for the fairly simple task at hand. If the
task were more complicated, there is no doubt this is the proper
route.
(b) The other option, a closure, makes the simple things simple, but
the harder things a bit harder. File uploads, for instance, and
cookies. Of course, since a Widget set rarely (if ever) would need to
display the content of an upload as part of a re-rendering of the
widget, I don't see this being a common use. Likewise, cookies don't
seem as needed to be for more or less the same reason (if you're using
raw cookies to pass complex data around, you're probably doing more
work than you need to; things like Apache::Session make life easier
without forcing you to muck with cookies at every data access point).
It gets ugly though if you -do- want cookies. Does your abstract base
class (ABT) have to be typed for every possible pair of form var
input and cookie input methods? Is there a separate interface for
each, thus complicating the API slightly?
The more I think about it, the more wrong it seems for the Widget
library to assume anything about where its data is coming from. It
should either be from a closure or a class based on an ABT. A third
option is that all widgets are actually generated by a generator
instance of a class; this could simplify the API so that you needn't
pass the CGI object or closure around all the time. In this case, you
could derive from this base class to create new ways of gathering data
from CGI and cookies.
This is more or less a standard design pattern -- data interfacing.
There are a number of solutions. I just hope whatever gets written is
present and future proof enough to not depend on any particular
interface (such as CGI or libapreq), or at the very least made to
easily use others. You never know when someone else may have another
templating technology that has a different interface!
Cheers,
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
