On Tue, 29 May 2001, James G Smith wrote:
> IMHO, having a configuration API is much better than requiring a particular
> way to do configuration. If the backend configuration is done via Perl code,
> then any configuration file format can be supported with an appropriate module
> handling it.
This is what I am advocating - widgets have properties of various flavours. We
describe how these properties and their different flavours operate. A lot of the
runtime functionality of how stuff arrives into existance should be the choice of the
developer. That includes things like XML, DBI, etc.
I think that the case for Storable as a core format could be made:
- its fast
- its reliable
- it can be translated into Perl code via Data::Dumper or XML through your favorite
XML module
> These widget configurations will need to be flexible enough that I can
> construct a page with them without any knowledge of how they will look -- the
> configurations should be tie-able to an overall theme for the site. I've
> always been a champion of themes for websites. I should be able to select a
> configuration at run-time without a lot of trouble.
I have not mentioned it yet - but I have been thinking that widgets should check their
container for the active theme to use. It would be up to the widget as to how it would
render itsself under different themes. To make that job easier - there are a number of
rendering elements that could potentially be re-used across widgets for an entire
theme....
ie/ current theme would be:
$widget->container->theme
just like when a widget goes to render itself it would be checking:
$widget->container->render_format
to see if it should use "HTML", "WAP", or whatever.
A container could be another widget or something more high level like an application
handler or template processor.
If a widget is serving as a container it probably won't hold the answer to things like
theme or format - instead it would pass the request along to its container and so on.
Jay
J
