At 10:51 PM +0800 5/31/01, Gunther Birznieks wrote:
>At 11:02 AM 5/29/01 -0400, Robert Landrum wrote:
>>At 9:53 PM +0800 5/29/01, Gunther Birznieks wrote:
>>>At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
[snip]
>>>>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.
>>
>>Yes, but that's only because it defines 4 widgets... I'd probably
>>expect somewhere between 50-100 widgets on average, and more the
>>500 in extreme cases.
>
>Really? I think you are an extreme case then. Do you really have
>more than 50 form elements on a page usually? I think the container
>of the widgets is roughly equivalent to a page that has to be
>rendered. It isn't necessarily every widget in the entire app.
Not on a single page, but throughout an entire site....
And we're not just talking about widgets that draw input boxes...
Widgets are any page elements, such as images, buttons, links, etc...
Right? Perhaps the way I've implemented widgets is different from
the way you implement widgets.
I define a widget as any configurable, reusable, code segment that
produces output intended to be view by the end user.
For instance, we have something called a
CapWiz::Widget::CongressToday. And to call it, you pass it data from
the database, and any configuration options, and out comes HTML.
my $w = CapWiz::Widget::CongressToday->new({
'data' => \@records_from_database,
'color' => '#CCCCCC',
'width' => 385
});
$r->print($w->draw());
And we have several hundred (200+) of these widgets to draw
everything from Member Vote Tallies to Navigation Elements.
Keep in mind that this is just how we have implemented widgets, and
our only requirement was that it output XHTML... Not WM/WAPL,
JavaScript, or GNOME/Gtk code.`
>
>>A perl hashref config file requires knowledge of perl data
>>structures, which most designers won't grasp. Since I'm not the
>>designer for my site, nor am I the guy
>
>This is true.
>
>>developing the underlying data structure, I wouldn't feel
>>comfortable using perl as the config file. XML makes for a nice,
>>easily understood medium for communicating configuration directives.
>
>Yes, but nice as an option. The worst part about an XML Config file
>is everyone will have differences of opinion about what to XMLify
>and how complex to make the defaults. So I think it's best as noted
>before, to leave as a subclass.
Agreed.
--
Rome didn't become great by having meetings; they did it by killing
all those who opposed them.
