At 10:08 AM 5/29/01 -0400, Jay Lawrence wrote:
>My $0.02 on XML config files. Although they may be attractive to some,
>personally, I don't like them.
I personally do like them, but I find XML to be heavy weight for parsing in
mod_cgi. And many of my users are on normal cheap ISPs that would not
compile XML::Parser.
I use XML config files in Java because the considerations are different and
you can't code a config file for Java in Java without suffering a compile
step for the end-user. I prefer config files written basically in Perl.
>I see XML is merely the expression of the configurable parameters of the
>object. IE it is just a means to the end. Personally, I would like to define
>my widget properties through a GUI and then will probably use Storable to
>dehydrate and rehydrate my widget objects. I would never want to code up XML
>data and I don't think I'm alone. :)
Yes, but I think serialization is a different API than construction. I
think the default construction/config API should be raw Perl code because
it would be FAST. Then optional to allow Config objects to create that raw
Perl code based on XML or properties files or whatever someone wants.
>Definately when it comes to interchanging your widget data with another
>system something like XML really starts to make sense. I don't think it
>makes sense necessarily for your internal day-to-day operations.
>
>What I would advocate is that there are a variety of sources for widget
>configuration data from something as simple and elegant as Perl code to XML
>of some layout to Storable data stored in a blob field of a DBI source.
>
>e.g.
> $widget->serialize( [ "Storable" ] )
> returns scalar ref to Storable data
> $widget->serialize("XML")
> returns scalar ref to XML string
>
> $widget->define( \$StorableData [, "Storable" ] )
> $widget->define( \$XMLData, "XML")
>
>Then you can easily write a Widget Controller that can be configured as to
>what method to use and where to store it to/from.
>
>Ideally these methods would always be inherited from the base widget class
>which will dictate the runtime implementation of widget data.
This seems reasonable.
