My $0.02 on XML config files. Although they may be attractive to some,
personally, I don't like them.
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. :)
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.
Jay
----- Original Message -----
From: "Gunther Birznieks" <[EMAIL PROTECTED]>
To: "Stephen Adkins" <[EMAIL PROTECTED]>; "Jay Lawrence"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, May 29, 2001 9:53 AM
Subject: Re: Real Widgets and Template Languages
> At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > >
> > >I don't understand the Widget::Controller. Can you say more about
this?
> > >
> > >Also will we require XML to configure? Or is this also an optional
feature
> > >that you more or less want for yourself but others can choose to not
use?
> > >
> >
> >Hi,
> >
> >Below is running code for the Perl Widget Library.
> >So far, there are only two widgets.
> >
> > * a generic Widget::HTML::Element
> > * a drop-down menu Widget::HTML::Select
> >
> >Are there early comments on the interface from Perl?
> >Is this shaping up into what was desired?
> >
> >Stephen
> >
> >shark:/usr/ov/acoc/dev/src/Widget/examples> more Widget.xml Widget.2
> >::::::::::::::
> >Widget.xml
> >::::::::::::::
> ><config>
> > <widget name="first_name" tag='input' type='text' size='14'
> >maxlength='99'/>
> > <widget name="last_name" widget-class='Widget::HTML::Element'
> >tag='input' type='text' size='14' maxlength='99'/>
> > <widget name="birth_dt" widget-type='date'/>
> > <widget name="sex" widget-type='sex'/>
> > <widget-type name="date" tag='input' type='text' size='14'
maxlength='99'/>
> > <widget-type name="sex" widget-class='Widget::HTML::Select'
domain='sex'/>
> > <domain name="sex">
> > <item name="M" label="Male"/>
> > <item name="F" label="Female"/>
> > </domain>
> ></config>
>
> This config seems simple enough that it doesn't seem that necessary to use
XML.
>
> >::::::::::::::
> >Widget.2
> >::::::::::::::
> >#!/usr/local/bin/perl
> >
> >use lib "..";
> >
> > use Widget;
> >
> > my ($wc, $widget, @widgets);
> > $wc = Widget->controller();
>
> Don't you need to provide the controller with a CGI object? I guess this
> part hasn't been necessary yet, so the widget controller is just like a
> hash allowing widgets to be associated by name.
>
> > $widget = $wc->widget("first_name");
> > print "First Name: ", $widget->html(), "\n";
>
> A widget type has already been defined. So I don't see that the method to
> output it's display should be called html() which is, well, HTML specific.
> I prefer
>
> print "First Name: ", $widget->display(), "\n";
>
> Since widgets are components that know how to display themselves whether
> its WML or HTML or whatever.
>
> Thanks,
> Gunther
>
>
