At 03:36 PM 5/31/01 -0400, Robert Landrum wrote:
>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:
>
>>>[...]
>>>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.`
I think the way you are describing widgets is somewhat different from how I
describe widgets. While widgets can be overloaded to be a draw-only
component, the idea behind widgets is really as an application medium *not*
a content management medium.
What you are describing is closer to a model like Zope. Whilst I agree that
content mgmt is important, my gut feeling is that there are subtle
differences that make abstraction of simply any component like this quite
hard. And that's exactly what I would call them, components.
A widget has a specific behavior and is meant to interact with an
application, have form data sent to it, have the data posted and sent back
to data validator in the CGI script. etc.... I am not a content management
guru, but I am frightened about the possibility that something as difficult
as CMS will break into a version 1 widget library unless it's really clear
that it won't bloat the API.
I do not have experience with CMS, but I imagine it must be complex or Zope
for Perl would already exist today. Although perhaps the same could be said
for widgets. :)
>>>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.
And I guess through this mechanism you could use widgets as your components
because you'll probably a very complex config because of how many widgets
you are dealing with in the scope of CMS.
Later,
Gunther
PS I am posting these last few msgs to mod_perl because I only just
subscribed to the sourceforge list (which I recommend everyone doing). But
I am waiting a day to let everyone else get caught up as well on signing up
so that the first posts will go to everyone.
