Re: Real Widgets and Template Languages
Gang, First, a reminder to sign up on perl-widget-developer if you want to keep up with this thread. Already there are posts going there that are *not* going to modperl. http://sourceforge.net/projects/perl-widget We have achieved Milestones 1 and 2. * Milestone 1 - a proof of concept prototype of code * Milestone 2 - a SourceForge project set up for it ... >Then given the assumption that those objects are simple, many more people >can implement them. If I have to be concerned about a lot of stuff >everytime I make a widget like multilingual support hooks and event hooks >then I will never write a widget because I don't have time. > >This is why I want widgets to be tiny and atomic. Let's make it simple. If >you want multilingual can there be some way of making the multilingual >features a wrapper around existing atomic widgets? Same for events and >other such expert features. ... It is absolutely my intent to satisfy the minimalist's needs. Gunther intends to use these widgets in a simple and elegant way which represents how *many* people will first use the Perl Widget Library. I promise that simple widgets will be simple to write. Frankly, complex widgets will be pretty simple to write. I want a module that fits into people's *existing* software. After that, they may find it valuable to expand and use the other features. I envision the following four user-driven Milestones. (Real users, real value!) If we satisfy the first-round needs of Gunther, Jay, and Stephen, we will have a set of software which meets many of your needs out there. I also don't want to put a lot of emphasis on what feature is in what release. Essentially, this is my attack plan. Any of you are free to accelerate the development of one or another feature. o Milestone 3: get it ready for Gunther Birzniek's needs x get HTML generation of Pods working to own site x get rid of -w warnings in cgi-bin/cgiexample o add named-parameters to constructors: Controller, State, Config o add named-parameter, "state_args" => $cgi o resolve $widget->value() and $widget->values() * When Gunther is happily using the PWL in his application, we will consider this milestone achieved. * Gunther, I am close to a release that I think will be usable to you. I may then need you to write a Widget::Config::Extropia or whatever and give me feedback on what sucked about the API. After that I need you to come up with a detailed checklist of changes that need to be made to achieve the milestone. (Of course we will discuss it all on the perl-widget-developer mailing list.) o Milestone 4: internationalization for Jay Lawrence's needs o incorporate concepts of internationalization (string lookup) o add Widget::HTML::TextLabel (?) widget with internationalization abilities o add Widget::HTML::Money (?) widget with internationalization abilities * When Jay is happily using the PWL in his application, we will consider this milestone achieved. * Jay, same for you as for Gunther. I just put his milestone before yours because I want to make the simple things simple. But of course we will be working on it all at the same time. o Milestone 5: enhance the vision for Stephen Adkins' needs o add Widget::HTML::Template widget o add Widget::HTML::DualOrderedMultiSelect widget o incorporate a "parent" concept into widgets, and event bubbling o incorporate concept of browser sensitivity o add support for Javascript in the o add cgi-bin/wexec (CGI script for running full-widget UI) * When Stephen is happily using the PWL in his application, we will consider this milestone achieved. o Milestone 6: Release as Widget-1.00 and announce to modperl and Perl community o get Pod documentation of classes up to speed o create a better statement of "what this is" o create a list of "have you ever wished that... ?" questions to interest people o add mod_perl support
Re: Real Widgets and Template Languages
At 03:50 AM 6/1/01 +0200, Issac Goldstand wrote:
> > At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
> > > > At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> > > > >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > > > > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > > > >...
> > >[...]
> > >
> > >Complex Widget:
> > >
> > >Y-Offset="20"
> > >TabStop="True" TabIndex="3" name="text1" value="some sample text"
> > >tooltip="Enter some text here"/>
> > >
> > >Now, let's say that the developer prints this with the HTML "Driver" -
>this
> > >could do something like:
> > > > >onMouseOut="Window.status=''"/>
> > >
> > >And in some other GTK-based environment, it could do something like:
> > >
> > >Label text1;
> > >with (text1)
> > >{
> > > .Length=50;
> > > .Width=25*XCharSize; // The *XCharSize would have to be defined by
>the
> > >driver or by the native interface
> > > .Height=1*YCharSize; // This would be a default setting "plugged in"
>by
> > >the driver
> > > .Value="some sample text";
> > > .Left=40;
> > > .Top=20;
> > > .TabStop=1;
> > > .TabIndex=2; // 3-1 for 0 based - also defined by the driver...
> > >}
> > >
> > >Now, neither of these cases used _all_ of the widget parameters - a
>simple
> > >HTML designer could have produced an IDENTICAL widget by doing:
> > >
> > >
> > >
> > >This shows a few things, actaully. First of all, the widget can get as
>many
> > >or few parameters as the developer wants to supply it with - extra
> > >parameters will be discarded by drivers who do not understand them, and
> > >missing parameters will be supplied with "default" values wherever
>possible.
> > >Now, I would suggest designing this such that the developer only
>interacts
> > >with a Widget::textbox. Internally, there would have to be a
> > >Widget::HTML::textbox and a Widget::GTK::textbox, each with the
>UI-specific
> > >rendering instructions...
> > >
> > >The only problem is making sure that the overhead is kept to a minimal -
>in
> > >that as few feautres that are not actually NEEDED for the specific
> > >implementation are loaded as possible (eg, a user using only certain
> > >elements in HTML will only load those elements, and only HTML, while if
>he
> > >wants WML, it will also incur WML generic overhead too). I think this
> > >approach should satisfy both the wants to keep the widgets as generic as
> > >possible, as well as Gunther's wanting to keep the widgets as simple and
> > >easy-to-use/understand as possible (for beginners, at least).
> >
> > While adding parameters to the constructor is not a problem, I guess I
>have
> > a problem with adding behaviors. If you believe that simply adding more
> > config hooks to allow XWindows to be supported is doable, then we should
> > just leave it as mentioning this as a supposition and leave it to you or
> > someone else to prove that the supposition works after v1.x of the widget
> > set is released.
> >
>
>For arguments sake, I suppose it can be left as a supposition (OK, so I'm
>too swamped just now to do a proof-of-concept [especially one that would
>require me to learn GTK programming - something I've not yet touched]).
>
>I still think that if a proper abstraction layer is implemented, then
>parameters can either be "guessed" or silently discarded, thus enabling the
>widgets to be rendered in anything - even XWindows (or Win32 using Vis
>Basic, or a dialog resource file). Note that in these cases, only very
>generic code can be generated, but it's still possible.
I would agree that the current widget set can be used to create a
displayable component for Xwindows instead of a string of HTML.
But it's all the event stuff and callbacks and the like that seem like
extending the widget abstraction to GUIs is dangerous when the widgets I
want only require the capability of being delivered based on a simple
request/response protocol of HTTP so that a request comes in, the
script/controller processes it and then static text or components are
delivered down the wire that is HTML or WML or whatever but it's still
request/response.
Anyway, I don't mean to force anything down specifically. But I do know
that making things complex also leads to a lack of adaptation and a lack of
time for developing components. What I would like to see happen is that a
simple API is discussed and agreed and the basic objects are created.
Then given the assumption that those objects are simple, many more people
can implement them. If I have to be concerned about a lot of stuff
everytime I make a widget like multilingual support hooks and event hooks
then I will never write a widget because I don't have time.
This is why I want widgets to be tiny and atomic. Let's make it simple. If
you want multilingual can there be some way of making the multilingual
features a wrapper around existing atomic widgets? Same for events and
other such expert features.
Re: Real Widgets and Template Languages
At 04:28 PM 5/31/01 -0700, brian moseley wrote: >On Thu, 31 May 2001, Gunther Birznieks wrote: > > > I think it can be supported through a custom subclass of > > what you have been describing as a container/controller > > for the widgets. I think if it is done at the widget > > level it is bloating the widget set and I honestly don't > > see why a widget should know about languages. > >depends on how granular your widgets are. if you have a menu >widget that also displays a label, the widget needs to know >where to place the label relative to the menu. this choice >will probably differ for various languages. course you add >some kind of location api to the widget, but then you're >bloating again. or you can just keep labels outside widgets >;) Yes, but this is a more direct containment than a form which is likely to have many elements in it other than widgets. In this case, a widget directly contains other widgets. I think this is potentially OK and makes it easy to create a template-based tag. But when you have to keep track of a form tag that has widgets inside but may have arbitrary HTML as well, it's a more difficult/complex problem. As I have mentioned in a previous mail here, I think a composite widget is probably reasonable (for the locale and html vs wml output) but likewise, a composite widget could also be used to configure other widgets displaying simultaneously (and not as a switch based on language) to determine order of menu items and labels and whatnot. While I think these examples are good and they show advanced thought in all sorts of things widgets can be used for. The reality is many of these things are exceptions that are usually more an issue for windows systems than the abstraction that I would like to deal with a majority of the time -- just making my dealing with FORMs easier than it is now, within a short period of time was and is my primary goal. If you can accomplish the things you want without changing the basic behavior and without forcing me to fill-in a huge API whenever I write a widget class, then that is fine. But I think we need to focus on the *core* API and getting the *core* objects out so that they can be used. I believe atomic widgets, if we can at least agree on that can be fine for me and all of you who want fancy stuff can write controllers and composite widgets that do you fancy stuff exactly the way you want. I just don't want the widgets themselves to be large and difficult to implement.
Re: Real Widgets and Template Languages
> At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
> > > At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> > > >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > > > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > > >...
> >[...]
> >
> >Complex Widget:
> >
> > >TabStop="True" TabIndex="3" name="text1" value="some sample text"
> >tooltip="Enter some text here"/>
> >
> >Now, let's say that the developer prints this with the HTML "Driver" -
this
> >could do something like:
> > >onMouseOut="Window.status=''"/>
> >
> >And in some other GTK-based environment, it could do something like:
> >
> >Label text1;
> >with (text1)
> >{
> > .Length=50;
> > .Width=25*XCharSize; // The *XCharSize would have to be defined by
the
> >driver or by the native interface
> > .Height=1*YCharSize; // This would be a default setting "plugged in"
by
> >the driver
> > .Value="some sample text";
> > .Left=40;
> > .Top=20;
> > .TabStop=1;
> > .TabIndex=2; // 3-1 for 0 based - also defined by the driver...
> >}
> >
> >Now, neither of these cases used _all_ of the widget parameters - a
simple
> >HTML designer could have produced an IDENTICAL widget by doing:
> >
> >
> >
> >This shows a few things, actaully. First of all, the widget can get as
many
> >or few parameters as the developer wants to supply it with - extra
> >parameters will be discarded by drivers who do not understand them, and
> >missing parameters will be supplied with "default" values wherever
possible.
> >Now, I would suggest designing this such that the developer only
interacts
> >with a Widget::textbox. Internally, there would have to be a
> >Widget::HTML::textbox and a Widget::GTK::textbox, each with the
UI-specific
> >rendering instructions...
> >
> >The only problem is making sure that the overhead is kept to a minimal -
in
> >that as few feautres that are not actually NEEDED for the specific
> >implementation are loaded as possible (eg, a user using only certain
> >elements in HTML will only load those elements, and only HTML, while if
he
> >wants WML, it will also incur WML generic overhead too). I think this
> >approach should satisfy both the wants to keep the widgets as generic as
> >possible, as well as Gunther's wanting to keep the widgets as simple and
> >easy-to-use/understand as possible (for beginners, at least).
>
> While adding parameters to the constructor is not a problem, I guess I
have
> a problem with adding behaviors. If you believe that simply adding more
> config hooks to allow XWindows to be supported is doable, then we should
> just leave it as mentioning this as a supposition and leave it to you or
> someone else to prove that the supposition works after v1.x of the widget
> set is released.
>
For arguments sake, I suppose it can be left as a supposition (OK, so I'm
too swamped just now to do a proof-of-concept [especially one that would
require me to learn GTK programming - something I've not yet touched]).
I still think that if a proper abstraction layer is implemented, then
parameters can either be "guessed" or silently discarded, thus enabling the
widgets to be rendered in anything - even XWindows (or Win32 using Vis
Basic, or a dialog resource file). Note that in these cases, only very
generic code can be generated, but it's still possible.
Re: Real Widgets and Template Languages
At 04:21 PM 5/31/01 -0700, brian moseley wrote: >On Thu, 31 May 2001, Gunther Birznieks wrote: > > > Let's put it this way, I have actually used widgets for > > the last 6 months in real world applications using JSPs > > and widget libraries in Java. I can't tell you what a > > joy it is to work with something so relatively simple > > and just easy to put things in a page. > >which widget libraries? Our own. But I understand Struts apache project has the same basic deal (as also confirmed by Matt Sergeant's post). And from looking at Struts I think their model is even simpler than the model we have in our Java toolkit. This is why I am quite frightened of all these additions to a widget API in Perl when I know it's been accomplished so simply as a framework in Java. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Real Widgets and Template Languages
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' => '#CC',
> '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.
Re: Real Widgets and Template Languages
At 09:14 PM 5/31/01 +0200, Issac Goldstand wrote:
> > At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> > >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> > >...
>[...]
> > >The caller in this case has already cooked up a bunch of HTML and is
> > >counting on the widget to produce HTML which can be inserted.
> > >The widget does *not* have the freedom to render any other way.
> > >This is why I have (sort of stubbornly) stuck with the $widget->html()
> > >method despite the unanimous suggestions for a $widget->display()
> > >method.
> >
> > and then also ->wml() and ->X() and whatever else? This does not seem
>right.
> >
> > >I do believe there is a place for a display() method, but it is at
> > >the controller level. The is the level at which the caller may not
> > >know what technologies are being used by the widgets.
> >
> > Yes its not at the controller level. It is at the widget level. So you
>have
> > Widget::WML::TextField and Widget::HTML::TextField...
> >
> > And the firsto ne would go into a controller that is set up to contain WML
> > widgets in general and the second would go into a controller that is set
>up
> > to contain HTML widgets in general.
>
>This is also doable, but only if it's transparent to the user. In other
>words, the developer _using_ the widget would have to mkae a
>Widget::TextField, and only when it was _rendering_ the Widget, would the
>libraries internally read the information in Widget::HTML::TextField or
>Widget::WML::TextField - otherwise, it's just not worth making "generic"
>widgets.
In my opinion, this is very difficult in practice. The widgets should be
atomic and do as little as possible. On occasion, application-specific
widgets would be created to do interesting things like Dates to pull
together several form fields.
However, I think you can accomplish this dispatching to WML and HTML
printing by using a composite widget or a widget container or the widget
controller. It doesn't really matter which abstraction is used. You can use
all 3 by merely subclassing widget and using a composite design pattern
without bloating the original API.
I want to keep the original API simple.
>[...]
> >
> > Here's my constructive criticism. The design constraint on the widgets
>here
> > is that you should assume a request/response model through HTTP for this
> > library and basically assume compatibility with template libraries that
>use
> > HTTP as a medium. X windows and curses and all that kind of stuff is not
> > appropriate and will confuse the API from an HTML perspective.
>
>I disagree. I think that by having dynamic parameters for the widgets, in
>conjunction with my "driver" idea, this can be made a lot more flexible
>without these problems. It would take planning out, but if we make the
>"snap-in" environment work correctly, then simple users who want easy HTML
>can do that easily, while a developer writing a template that will display
>on X-Windows as well as it will on a cellphone screen gets the HUGE benefit
>of constant widgets in a single template. Now for advanced stuff, we may
>very well need complex parameters - possibly even on a per-widget basis -
>but this should be on an "extended parameters" basis.
I disagree because the *behavior* of widgets in a free form, event driven
environment is much more complex than a request/response protocol. Behavior
differences means added methods and added complexity to the protocol as
well as what a developer has to do to implement a widget.
It's quite possible that it was wrong to call this a widget project and it
should really be HTTP::Widgets because I don't think these are widgets you
want to use in Perl/TK.
>Since I'm actually starting to trip over my own words here, let me try to
>illustrate with an example (note that I'm pulling methods and objects out of
>thin air - the idea is to illustrait the idea I brought up, not necessarily
>offer a draft of it):
>
>Complex Widget:
>
>TabStop="True" TabIndex="3" name="text1" value="some sample text"
>tooltip="Enter some text here"/>
>
>Now, let's say that the developer prints this with the HTML "Driver" - this
>could do something like:
>onMouseOut="Window.status=''"/>
>
>And in some other GTK-based environment, it could do something like:
>
>Label text1;
>with (text1)
>{
> .Length=50;
> .Width=25*XCharSize; // The *XCharSize would have to be defined by the
>driver or by the native interface
> .Height=1*YCharSize; // This would be a default setting "plugged in" by
>the driver
> .Value="some sample text";
> .Left=40;
> .Top=20;
> .TabStop=1;
> .TabIndex=2; // 3-1 for 0 based - also defined by the driver...
>}
>
>Now, neither of these cases used _all_ of the widget parameters - a simple
>HTML designer could have produced an IDENTICAL widget by doing:
>
>
>
>This shows a few things, actaully. First of all, the widget can get as many
>or few parameters as the d
Re: Real Widgets and Template Languages
On Thu, 31 May 2001, Gunther Birznieks wrote: > Hmmm, I don't know about memory savings. But the feature > you've outlined here could be taken advantage of by > widgets but I don't think it should be part of the > widget library. I think it's better as a separate CPAN > module for dealing with I18N in general and maybe it > already exists... yeah, it's called gettext.
Re: Real Widgets and Template Languages
On Thu, 31 May 2001, Gunther Birznieks wrote: > I think it can be supported through a custom subclass of > what you have been describing as a container/controller > for the widgets. I think if it is done at the widget > level it is bloating the widget set and I honestly don't > see why a widget should know about languages. depends on how granular your widgets are. if you have a menu widget that also displays a label, the widget needs to know where to place the label relative to the menu. this choice will probably differ for various languages. course you add some kind of location api to the widget, but then you're bloating again. or you can just keep labels outside widgets ;)
Re: Real Widgets and Template Languages
On Thu, 31 May 2001, Gunther Birznieks wrote: > Let's put it this way, I have actually used widgets for > the last 6 months in real world applications using JSPs > and widget libraries in Java. I can't tell you what a > joy it is to work with something so relatively simple > and just easy to put things in a page. which widget libraries?
Re: Real Widgets and Template Languages
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
::
>>>maxlength='99'/>
>>>tag='input' type='text' size='14' maxlength='99'/>
>>>
>>>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' => '#CC',
'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.
Re: Real Widgets and Template Languages
> At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
> >At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> > >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
> >...
> > >>$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.
> >
> >This is a philosophical design decision that I have been struggling with.
> >The widget does indeed know that it should generate HTML, so it could
have
> >a method, $widget->display(), $widget->draw(), etc.
> >
> >However, this implies that the widget has the freedom to decide how it
> >should render itself and that the caller does not need to know.
> >This is not correct.
>
> I think it is correct. The widgets are specific to the technology like
HTML
> or WML or whatever. It's up to your config in the Controller to determine
> which widgets you are putting into the controller.
>
> If you want to display both WML and HTML, you would create a WML
controller
> and an HTML controller. Note that the controller itself doesn't know the
> difference, but you just are using it as a collection mechanism to group
> together like-sets of widgets.
This is true, but that's not a really good design plan. Now I still haven't
quite understood how the different base classes work together, so I can't
suggest a specific implementation strategy yet, but IMHO you should be able
to create Widgets dynamically for any target UI, with widgets that are
nativelly unsupported in a specific UI (eg, WML vs HTML) doing some default
action (AUTOLOAD somewhere?). Now I agree with Gunter in that
$MyWidget->DisplayHTML() vs $MyWidget->DisplayWML() is the wrong way of
doing it. But I was sorta thinking along DBI's way of doing things in that
you load a "driver" first - the "driver" being the UI link, and then
$MyWidget->Display() would automatically use the correct "driver" for
outputting stuff.
Before I go any further, I should mention that I still haven't understood
all of the terms that Stephen uses when describing the Widgets, so if I'm
repeating something here that anyone already said, please let me know what
part of the existing interface I'm describing...
Now, the only problem is how to make the "default" actions (for Widgets that
are unsupported by the "driver"). I need to think about this a bit more,
but it'll probably take an AUTOLOAD per-widget and/or a specific function
(not AUTOLOAD) per-driver...
> >The caller in this case has already cooked up a bunch of HTML and is
> >counting on the widget to produce HTML which can be inserted.
> >The widget does *not* have the freedom to render any other way.
> >This is why I have (sort of stubbornly) stuck with the $widget->html()
> >method despite the unanimous suggestions for a $widget->display()
> >method.
>
> and then also ->wml() and ->X() and whatever else? This does not seem
right.
>
> >I do believe there is a place for a display() method, but it is at
> >the controller level. The is the level at which the caller may not
> >know what technologies are being used by the widgets.
>
> Yes its not at the controller level. It is at the widget level. So you
have
> Widget::WML::TextField and Widget::HTML::TextField...
>
> And the firsto ne would go into a controller that is set up to contain WML
> widgets in general and the second would go into a controller that is set
up
> to contain HTML widgets in general.
This is also doable, but only if it's transparent to the user. In other
words, the developer _using_ the widget would have to mkae a
Widget::TextField, and only when it was _rendering_ the Widget, would the
libraries internally read the information in Widget::HTML::TextField or
Widget::WML::TextField - otherwise, it's just not worth making "generic"
widgets.
> >This whole discussion brings out two other important design decisions.
> >
> > 1. What are the UI technologies we really wish to support?
> > (i.e. is this *really* a Widget or an HTML::Widget library?)
> > 2. Which classes represent Logical Widgets and which Physical Widgets?
> >
> >1. TECHNOLOGIES
> >
> >I propose that the following technologies will have supporting
> >Controller/State/Widget combinations to make this not just another web
> >widget library.
> >
> > * CGI/HTML - a web application
> > * mod_perl/HTML - similar, a web application using mod_perl
> > * WAP/WML - driven from a WAP device
> > * X11 (Gtk-Perl)- an X windows application
> > * Curses (terminal) - a screen-oriented terminal application
> > * Term - a line-oriented (scrolling) terminal application
> > * Cmd - similar to Term, but the state must
Re: Real Widgets and Template Languages
At 12:31 PM 5/29/01 -0400, Stephen Adkins wrote:
>At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
> >At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
>...
> >>$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.
>
>This is a philosophical design decision that I have been struggling with.
>The widget does indeed know that it should generate HTML, so it could have
>a method, $widget->display(), $widget->draw(), etc.
>
>However, this implies that the widget has the freedom to decide how it
>should render itself and that the caller does not need to know.
>This is not correct.
I think it is correct. The widgets are specific to the technology like HTML
or WML or whatever. It's up to your config in the Controller to determine
which widgets you are putting into the controller.
If you want to display both WML and HTML, you would create a WML controller
and an HTML controller. Note that the controller itself doesn't know the
difference, but you just are using it as a collection mechanism to group
together like-sets of widgets.
>The caller in this case has already cooked up a bunch of HTML and is
>counting on the widget to produce HTML which can be inserted.
>The widget does *not* have the freedom to render any other way.
>This is why I have (sort of stubbornly) stuck with the $widget->html()
>method despite the unanimous suggestions for a $widget->display()
>method.
and then also ->wml() and ->X() and whatever else? This does not seem right.
>I do believe there is a place for a display() method, but it is at
>the controller level. The is the level at which the caller may not
>know what technologies are being used by the widgets.
Yes its not at the controller level. It is at the widget level. So you have
Widget::WML::TextField and Widget::HTML::TextField...
And the firsto ne would go into a controller that is set up to contain WML
widgets in general and the second would go into a controller that is set up
to contain HTML widgets in general.
>This whole discussion brings out two other important design decisions.
>
> 1. What are the UI technologies we really wish to support?
> (i.e. is this *really* a Widget or an HTML::Widget library?)
> 2. Which classes represent Logical Widgets and which Physical Widgets?
>
>1. TECHNOLOGIES
>
>I propose that the following technologies will have supporting
>Controller/State/Widget combinations to make this not just another web
>widget library.
>
> * CGI/HTML - a web application
> * mod_perl/HTML - similar, a web application using mod_perl
> * WAP/WML - driven from a WAP device
> * X11 (Gtk-Perl)- an X windows application
> * Curses (terminal) - a screen-oriented terminal application
> * Term - a line-oriented (scrolling) terminal application
> * Cmd - similar to Term, but the state must be saved
>between each cmd
>
>(I know I'm stretching the paradigm a little bit here, probably beyond what
>is reasonable.
>If you don't think one or more of these is a good idea, please keep it to
>yourself.
>I have a vision for it, and even if it's not very useful, it will shape the
>"abstractness"
>of the design elements. On the other hand, I would welcome suggestions for
>additional
>UI technologies that I might consider supporting.)
>
>One of the primary design rules is to *not* fall into the "least common
>denominator"
>trap. Many cross-platform application frameworks have done this and failed.
>Rather, the design goal is to *enable* the widget to fully utilize the
>capabilities
>of the technical environment it is in.
I very much disagree.
Least common denominator is not a trap. It's a design decision. This is why
design patterns have consequences. Different design choices mean different
things. I think you ask for failure and bloatedness when you try to ask too
much of an API.
The attempt to make this widget library even encompass X-Windows and normal
GUIs is frustrating to me. As I have mentioned in a previous mail, I
already use this technology on Java and JSPs. This is taking a small and
simple concept and blowing it way out of proportion.
Ok, that's the end of that rant and rave.
Here's my constructive criticism. The design constraint on the widgets here
is that you should assume a request/response model through HTTP for this
library and basically assume compatibility with template libraries that use
HTTP as a medium. X windows and curses and all that kind of stuff is not
appropriate and will confuse the API from an HTML perspective.
>This brings me to the next topic.
>
>2. LOGICAL vs. PHYSICAL USER INT
Re: Real Widgets and Template Languages
At 05:14 PM 5/29/01 -0500, James G Smith wrote:
>[EMAIL PROTECTED] wrote:
> >Where is this language value coming from? The widget's container. You only
>care about English? Then set it to "EN-US" and forget it.
>[snip]
> >Implementation strategies can be as simple as:
> >
> >
> >sub label {
> >
> > my $self=shift;
> > my $lang=shift || $self->container->language;
> >
> > if (exists $self->{'label'}{$lang}) {
> > return $self->{'label'}{$lang};
> > }
> > return $self->{'label'}{$self->container->language('default');
> >
> >}
>
>Something I've seen elsewhere is to have a master table of strings that the
>widgets can then reference.
>
>Different ways of doing this:
>index strings by number (MicroSoft resources in executables);
>index strings by the string in a particular language (TWIG with
> English as
>the indexing language).
The latter is what Java does by default with resource files associated with
servlets.
>This allows for sharing of strings across widgets and memory savings,
>always a
>good thing in mod_perl. It also doesn't slow the system down much if any
>compared to storing the strings in each widget with duplication.
Hmmm, I don't know about memory savings. But the feature you've outlined
here could be taken advantage of by widgets but I don't think it should be
part of the widget library. I think it's better as a separate CPAN module
for dealing with I18N in general and maybe it already exists...
Re: Real Widgets and Template Languages
At 10:23 AM 5/29/01 -0500, James G Smith wrote: >Gunther Birznieks <[EMAIL PROTECTED]> wrote: > >At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote: > >>The rendering of this widget as HTML requires at least the following > >> > >>* config information (Widget::Config) >[snip] > >> >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? > >> > >>Configuration data is read in via the Widget::Config class, and this class >can > >>be replaced with a class which reads config data from any other source, as > >>long as > >>it conforms to the same calling interface. > >> > >>I was under the impression that XML was your desired means of writing a > >>config file. > >>Do you have a preference to use something different? > > > >I like XML for Config files, we use that in our Java stuff all the time. > >But Perl is one of the nicest and flexible config file languages out there. > >IE My config file is Perl. > > > >Anyway, I think it is weird to think of configuring just widgets. Usually > >you configure an application and widgets are a part of that. But everyone > >here will have a different way of preferring to write their application > >config whether it's XML or Perl and what features of these that are used > >(eg just a set of scalars or references to hashes or ... ?) or in the case > >of XML using attributes versus subtags... > >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. YES! >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 agree. I think this is basically a capability that exists in the rough draft of the widgets though.
Re: Real Widgets and Template Languages
At 10:27 AM 5/29/01 -0400, Stephen Adkins wrote: >At 09:49 PM 5/29/2001 +0800, Gunther Birznieks wrote: > >At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote: > >>Hi, > >> > >>Development of a straw-man set of Perl Widget Library core classes is > >>going well. A Sourceforge project (perl-widget) is in the process of being > >>set up too. (I will announce when it is set up.) >... > >>The state information can be accessed from *any* source by implementing an > >>appropriate > >>WidgetState class (and using some additional, > >>not-yet-implemented arguments > >>to Widget->controller()). > > > >I think it would be better as a Widget::State:: rather than the > >other way around. From the way you describe it, this is really an interface > >to getting state information that should be retrieved from a DataSource > >specific state driver. > >I have come to the same conclusion. >I am changing the design to have three core base classes (other than the >widgets): > >Widget::Controller >Widget::Config >Widget::State > >A CGI program might run with the following derived classes: >(These are the initial defaults I am working on.) > >Widget::Controller::CGI >Widget::Config::XML >Widget::State::CGI > >All of these "drivers" may be overridden, as long as the driver you replace it >with conforms to the interface definition described by the core base classes. >(Kind of like a Java interface. You would be encouraged to derive from the >core base classes, but that is not necessary.) >... I think this is good. > >> > > >> >I don't understand the Widget::Controller. Can you say more about this? > >> > >>The Widget::Controller (or perhaps, Widget::CGI::Controller) is the > >>container class > >>that you spoke about in your original post. I call it a Controller rather > >>than > >>a Container because I envision it being able to dispatch events generated > >>by the > >>widgets. > > > >Ah. I just want something to contain the widgets essentially. So perhaps > >from my perspective events aren't necessary and I would potentially just > >place the widgets into an array representing my HTML screen. > > > >I have found that event handling comes in surprisingly handy even for >simple tasks. >Essentially, it allows widgets to define callbacks. >For instance, the DateDropDowns widget defines an event "change" >(modelled after the Javascript "onChange" event) that, when triggered, >concatenates >the , MM, and DD back into -MM-DD. >The following is working code. >Notice that the "$wc->dispatch_events($query);" statement takes care of >whatever widget housecleaning there may be (in this case, recomposing the date >as a single variable from the three drop-downs). Oh that's what you mean by events. Hmmm. I don't think this is really an event as much as a massaging of data back and forth based on the widget data source interface. I don't think there are really events like JavaScript, so it seems to me like it would be a bit confusing to apply a model that is based around a real UI like JavaScript to something that is purely a simple request/response protocol. >I had the hunch that everyone's configuration needs would be different. >Hence the Widget::Config (interface) and Widget::Config::XML (driver) >design. (Thanks for the input.) I think this is reasonable. Although if you see my post to Jay, I would prefer if the core config is then through Perl data structures. And then all the drivers would map the XML and what have you to the Perl data structures that are native for speed.
Re: Real Widgets and Template Languages
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: >>> > 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 >>>:: >>> >maxlength='99'/> >tag='input' type='text' size='14' maxlength='99'/> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>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. >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. >>print "First Name: ", $widget->display(), "\n"; >>Since widgets are components that know how to display themselves whether >>its WML or HTML or whatever. > >What about draw? display might be misinterpreted. If I draw something, >does that mean I've displayed it? Under the Xwindow system, widgets are >drawn and then shown, IIRC... > >print "First Name: ", $widget->draw(),"\n"; I think this is a very good interface.
Re: Real Widgets and Template Languages
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.
Re: Real Widgets and Template Languages
At 10:04 AM 5/29/01 -0700, [EMAIL PROTECTED] wrote:
>On Tue, 29 May 2001, Stephen Adkins wrote:
>
> > Right. I have many more requirements I eventually want to support
> > (such as internationalization). The trick is making the design such
> > that it works in the simple case for simple things, while supporting
> > advanced features for those who wish to use them. I think it is coming
> > together pretty well.
>
>I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right off
>the top. If my widgets aren't multilingual then I'll have to go elsewhere.
>75% of my apps are bi and trilingual.
Sounds kinky.
Anyway, I think there are two things that have to be gotten straight.
1) I18L support should exist immediately such as being able to render a
Chinese label.
2) Multilingual support is VERY different from I18L and is MUCH more
complex. I vote no on supporting this.
I think it can be supported through a custom subclass of what you have been
describing as a container/controller for the widgets. I think if it is done
at the widget level it is bloating the widget set and I honestly don't see
why a widget should know about languages.
I should rather configure my widgets in French and other widgets in English
etc... And then I tell a multilingual container subclass about all my sets
of widgets and then using a setLocale(), then the getWidget() method will
return the appropriate configured language widget.
You also would need a Widget Config that is multilingual and can configure
the multi languages very easily.
But please do not touch the core widget api itself. Please please keep it
lightweight.
>I think we should bite the bullet and start talkin Unicode and ISO-639
>language codes right at the beginning.
>
>If a widget has a textual element to be used in rendering (ie/ label) it
>should have as many language forms as the developer requires. If a
>language form is missing it should kick down to a default language (EN-CA
>for example - otherwise words like colour and flavour will be mispelled ;-) ).
>
>Where is this language value coming from? The widget's container. You only
>care about English? Then set it to "EN-US" and forget it.
>
> $widget->container->language="EN-CA"
> print $widget->label
>"What is your favorite flavour of ice cream?"
>
> $widget->container->language="EN-US"
> print $widget->label
>"What is your favorite flavor of ice cream?"
>
> $widget->container->language="FR-CA"
> print $widget->label
>""
>
>I'm sure you see the pattern.
>
>Not every property should be considered polylingual but ones that contain
>textual or language-specific visual elements should be.
>
>Implementation strategies can be as simple as:
>
>
>sub label {
>
> my $self=shift;
> my $lang=shift || $self->container->language;
>
> if (exists $self->{'label'}{$lang}) {
> return $self->{'label'}{$lang};
> }
> return $self->{'label'}{$self->container->language('default');
>
>}
>
>My personal strategy to date is to create meta data describing the class
>in general. Accessor functions for properties are created dynamically via
>AUTOLOAD mechanism. Based on metadata for class in question the AUTOLOADer
>will setup the accessor using one of a few different behaviors.
>
>In closing - although it seems like a drag in the beginning - it really
>makes sense to develop applications and components to support multiple
>languages. It is a zillion times more difficult to cobble in the
>fucntionality after the fact.
Just don't make the core library have to support multilingual. This is just
another bloated thing I don't want. It's fine for the hooks to exist, but
not the logic.
I don't mind if you make a subclass to support multiple sets of widgets as
described above, but please do not add so much that this becomes a huge
project.
Re: Real Widgets and Template Languages
At 05:52 PM 5/28/01 -0400, you wrote: > > Let's focus a bit. > Specifically on requirements more than implementation - *GOOD* I think you misread my intention. I think the requirements are simple and fairly clear except for some interesting enhancements people (includign yourself) propose on the list. I'd like to get a set of objects out more quickly that only do a few things well and in a small lightweight interface. >Could I paraphrase or reinterpret what you have said to be base classes >for handling widget properties and data sources? > >In the web world I see data coming from: > static widget properties - design/configuration values > user supplied values - Session and Request values > data sources - RDBMS, LDAP, yadda > >In addition I do see a variety of flavours for this data: scalar, array, >hash. Me, I want even more exotic flavours such as language sensitive (The >lable property check's user's language choice and will give them back the >lable in the right language). In order for a widget set to be useful we have >to agree on how to pass around a certain set of potentially complex data >types. > >READ: robust base object class with potentially fancy strategy for >rationalizing a number of data sources and data structures. This is very vague to me. It just doesn't sound very concrete enough. I think an interface to be able to do reference to a hash where values are either ref to an array or scalar is good enough initially. >Additionally - when it comes to widget-specific actions - such as rendering, >then you're seeing this as a subclass (or group of methods) that has been >defined by the widget creator. > ie/ widget->render - generic method that checks container and calls >appropriate render subclass for this widget > since container is HTML return widget->render_HTML or whatever. I think breaking out render subwidgets is too complex for my tastes. >READ: object hierarchy. Objects check their parents for hints on how to do >things - like pick the form to render themselves, etc. > > > 1. Data Validation logic. No, this does not belong there. This is a > > separate library. I already have a rich Data handling library in my >toolkit > > that I intend to plug widgets into. All I need is to be able to get widget > > data from the data handling/validation library. > >If I place a widget into my user interface and allow a user to specify a >value how I am I to implement validation? > >ie/ Widget has property "choice" which can be "1","2", or "3". If the user >supplies any other value I want choice to be NULL and raise an error. > > A - does controlling application logic enforce choice validation > B - does widget have property information to say that choice property >must pass some validation process? > >I like B because it further compartmentalizes the behaviors of the widget >within its own specification. The source of the valication routines can be >external to the widget and classes but the validation rules would be >specified within here. This is exactly why config should not be part of the widget library except as a side optional item. You can make your config also optionally configure data handling rules, but mine might not. Then its up to your app toolkit (if it wants to) to set up the data handler methods to be called when the form is submitted to the CGI based on that config. > > 2. External display stuff. No, I just want the widget to know how to draw > > itself and only itself. It's up to a template language plugin like TT or > > some other template language to provide the wrappings. Or it can be a > > toolkit like your drawing forms library -- but the widget itself shouldn't > > have to know about external decoration around it. Just how to draw itself. > >If one is to create an HTML form on a web page then all of the form elements >should actually be contained within in a FORM container. The FORM container >can then facillitate the correct development of HTML etc. > >If the widgets are used within another context then the FORM container might >be necessary or it might not. But it is usually easier to ignore than try to >backpeddle and whack stuff in after its kinda too late. It's pretty rare for this to be an issue. If it is, I would rather see a form become a widget that is linked to another widget if you really require functionality like this. > > It's possible, but I am not quite sure because the primary complexity >seems > > to be the data handling (which I have already in a separate abstraction) > > and the UI generation which I have already in Template Toolkit. So all I > > really want is an object abstract called a Widget along with a > > WidgetCollection to allow grouping widgets together that belong on a given > > HTML page. > >The way I am seeing a solution come together is somewhat different. First of >all I am now tending to really really really want to work with persistant >object collections. As my application needs new
Re: Real Widgets and Template Languages - MOVING THE DISCUSSION
Dear Mod_Perl & Widget enthusiasts, Thanks to Stephen Adkins taking the bull by the horns we have a new Sourceforge project for the development of Perl Widgets strategies and code. To get the discussion off the mod_perl list - we're encouraging all those interested to join the perl-widget-developer list at: http://lists.sourceforge.net/lists/listinfo/perl-widget-developer In addition, you will be able to track progress and contribute to the cause directly via Sourceforge: http://sourceforge.net/projects/perl-widget/ and via two additional lists: http://lists.sourceforge.net/lists/listinfo/perl-widget-announce http://lists.sourceforge.net/lists/listinfo/perl-widget-users I know we all look forward to the results of this development effort and your valuable contributions. Jay Lawrence
Re: Real Widgets and Template Languages
On 29 May 2001 [EMAIL PROTECTED] wrote:
> On Tue, 29 May 2001, Stephen Adkins wrote:
>
> > Right. I have many more requirements I eventually want to support
> > (such as internationalization). The trick is making the design such
> > that it works in the simple case for simple things, while supporting
> > advanced features for those who wish to use them. I think it is coming
> > together pretty well.
>
> I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right
> off the top. If my widgets aren't multilingual then I'll have to go
> elsewhere. 75% of my apps are bi and trilingual.
I agree. I18L and L10N are very important these days.
> I think we should bite the bullet and start talkin Unicode and ISO-639
> language codes right at the beginning.
>
> If a widget has a textual element to be used in rendering (ie/ label)
> it should have as many language forms as the developer requires. If a
> language form is missing it should kick down to a default language
> (EN-CA for example - otherwise words like colour and flavour will be
> mispelled ;-) ).
But it's not just textual elements that need to be multilingual. Where is
really gets hairy is with something like a price widget (what monetary
symbol is used, what decimal point, etc...). This isn't usually that hard
to do on one system (if it has good Locale support), but making it cross
platform and dependable will be more difficult. I have used the
Locale::Maketext module with some success in the past. It doesn't depend
on any system Locality libraries, you are required to build them yourself
for your specific needs.
Another thing to consider is how to handle language issues with
dynamically changing widgets. For example if a widget uses a select box
it could be filled in by one of three ways: hard-coded, config, or at run
time (through DB calls or something). If your application is
multi-language, then you need to provide multiple datasets to the widget
if it is a dynamically changing widget. This would probably be most
convenient by using closures:
my $dbh = <>
$wc = Widget->controller();
$wc->language('fr_CA','fr','en'); # Tell the controller what language(s)
# you would like in order of precidence
my $get_categories = {
my $lang = shift; # will be one of (en, fr, fr_CA)
return $dbh->selectrow_array(q{
SELECT category
FROM categories
WHERE language = ?
ORDER BY category
}, $lang);
}
my $categories = $wc->widget("dynamic_select",
{ label => 'Category', dataset => $get_categories });
I don't think the widget should automatically check the users environment
(Language headers in the case of http), to decide what language to display
itself in. The reason for this is that I might only translate my website
into english and french, but the user has dutch as their preferred
language. The site should not display some parts in english/french and
it's widgets in dutch...
So by telling the controller what languages are acceptable, you can
restrict what it can do. Or perhaps the language should be decided by the
programmer at display time??
ie print $categories->display({language => 'fr_CA'});
That would get awful repetative if your displaying 20 widgets. But it
might be nice if you want to override a widget to display it in a
different language. Who knows what people might want :)
Handling the different language tags should probably be handled by
I18N::LangTags. You can pass it a string ($r->header_in('Language'), and
it will return an array of valid RFC1766-style language tags.
Sorry if it sound like I'm rambling, but I'm just throwing down thoughts
as they pop into my head :)
--
Cees Hek
SiteSuite Corporation
[EMAIL PROTECTED]
Re: Real Widgets and Template Languages
Wait a second, here... I was under the assumption that the Widget library was not going to be limited to HTML output only. According to your page, it seems that the only customization that you plan on doing is to modify the HTML to work properly with specific browsers (eg, MSIE vs Mozilla/Netscape). I think it's an important idea to leave the Widget totally language independant - so thast in addition to HTML, you could render these widgets on cell phones (WML) or Palm Pilots or whatever... Hell, you _should_ theoretically be able to render these using Win32 API if someone decided to write code to export to C/C++ or VB - or Ximian/GNOME - or whatever! Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Real Widgets and Template Languages
On Tue, 29 May 2001, Stephen Adkins wrote: > I completely understand what all three of you are saying, and I think the > needs of the Gunther and Jay are being accommodated in the new design. > > However, a note on XML and Storable ... > > The XML::Simple class allows you a "cache" option (which I am using) > where it caches the perl data structure in a Storable. > The XML::Simple class reads the XML file into a perl data structure, > then stores it as a Storable. On subsequent reads, it checks the > timestamps of the .xml file and the .stor file and only rereads the > XML file if it is newer than the .stor file. Otherwise, it just > reads the .stor file. This appears to be about 3x faster. Not really worth it... XML::LibXML is about 10 times faster anyway. Although the syntax to access bits of the XML is XPath, rather than a perl hash, but you get used to that pretty quickly. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Real Widgets and Template Languages
At 03:42 AM 5/30/2001 +0200, Issac Goldstand wrote: >Wait a second, here... I was under the assumption that the Widget library >was not going to be limited to HTML output only. According to your page, it >seems that the only customization that you plan on doing is to modify the >HTML to work properly with specific browsers (eg, MSIE vs Mozilla/Netscape). ... > > Issac Don't get worked up. The documentation on the page is about a week old. http://www.officevision.com/pub/Widget/ The link to the code is the only new addition. All of the comments you have read on this mailing list are accurate. I recommend you download the code, take a look, then comment. Stephen
Re: Real Widgets and Template Languages
At 10:04 AM 5/29/2001 -0700, [EMAIL PROTECTED] wrote: >On Tue, 29 May 2001, Stephen Adkins wrote: > >> Right. I have many more requirements I eventually want to support >> (such as internationalization). The trick is making the design such >> that it works in the simple case for simple things, while supporting >> advanced features for those who wish to use them. I think it is coming >> together pretty well. > >I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right off the top. If my widgets aren't multilingual then I'll have to go elsewhere. 75% of my apps are bi and trilingual. > >I think we should bite the bullet and start talkin Unicode and ISO-639 language codes right at the beginning. > OK. The priority of internationalization has been increased. Here is the first snapshot of code. http://www.officevision.com/pub/Widget/ Soon I will have the Sourceforge site up and we can stop clogging up this mailing list. Stephen
Re: Real Widgets and Template Languages
James, Yeh - that idea has merit. We don't always see that concepts map 1:1 between languages but probably 99% of the time it should be ok. Of course it is the 1% case that drives most people totally nuts. What might be of interest is a data type that is smart enough to hunt down its text tag from a text resource dictionary or use a string that is local just to that widget I am hesitant to advocate the use dictionaries because I do find them a bit confusing and unwieldly to think about managing in the context of a big web site. * Jay * I don't know about you guys - but when I am building stuff - I am also keeping in mind that humons [sic] will be doing much of the tweeking and managing of the site. Keeping systems simple is a big objective too! > Something I've seen elsewhere is to have a master table of strings that the > widgets can then reference. > > Different ways of doing this: >index strings by number (MicroSoft resources in executables); >index strings by the string in a particular language (TWIG with English as > the indexing language). > > This allows for sharing of strings across widgets and memory savings, always a > good thing in mod_perl. It also doesn't slow the system down much if any > compared to storing the strings in each widget with duplication. > -- > James Smith <[EMAIL PROTECTED]>, 979-862-3725 > Texas A&M CIS Operating Systems Group, Unix > > >
Re: Real Widgets and Template Languages
[EMAIL PROTECTED] wrote:
>Where is this language value coming from? The widget's container. You only
care about English? Then set it to "EN-US" and forget it.
[snip]
>Implementation strategies can be as simple as:
>
>
>sub label {
>
> my $self=shift;
> my $lang=shift || $self->container->language;
>
> if (exists $self->{'label'}{$lang}) {
> return $self->{'label'}{$lang};
> }
> return $self->{'label'}{$self->container->language('default');
>
>}
Something I've seen elsewhere is to have a master table of strings that the
widgets can then reference.
Different ways of doing this:
index strings by number (MicroSoft resources in executables);
index strings by the string in a particular language (TWIG with English as
the indexing language).
This allows for sharing of strings across widgets and memory savings, always a
good thing in mod_perl. It also doesn't slow the system down much if any
compared to storing the strings in each widget with duplication.
--
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
Re: Real Widgets and Template Languages
Stephen Adkins <[EMAIL PROTECTED]> wrote:
>At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
>>At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
>...
>>>$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.
>
>This is a philosophical design decision that I have been struggling with.
>The widget does indeed know that it should generate HTML, so it could have
>a method, $widget->display(), $widget->draw(), etc.
>
>However, this implies that the widget has the freedom to decide how it
>should render itself and that the caller does not need to know.
>This is not correct.
Actually, it could be. It would allow for general templates of widgets that
are not specific to any particular format (thinking of the standard template
library in C++). Perhaps overloading the stringizing operator for output... >
:)
>The caller in this case has already cooked up a bunch of HTML and is
>counting on the widget to produce HTML which can be inserted.
>The widget does *not* have the freedom to render any other way.
>This is why I have (sort of stubbornly) stuck with the $widget->html()
>method despite the unanimous suggestions for a $widget->display()
>method.
The actual output code could be controlled by a configuration option -- if the
configuration is help in another object that the widget can query, then the
caller will not *have* to know, though it could know, which format the widget
will be rendered as.
>I do believe there is a place for a display() method, but it is at
>the controller level. The is the level at which the caller may not
>know what technologies are being used by the widgets.
Agree... but I don't see why we can't push this down as low as possible so we
don't have to know how we are rendering until the absolute last possible
moment.
>1. TECHNOLOGIES
>
>I propose that the following technologies will have supporting
>Controller/State/Widget combinations to make this not just another web
>widget library.
>
> * CGI/HTML - a web application
> * mod_perl/HTML - similar, a web application using mod_perl
> * WAP/WML - driven from a WAP device
> * X11 (Gtk-Perl)- an X windows application
> * Curses (terminal) - a screen-oriented terminal application
> * Term - a line-oriented (scrolling) terminal application
> * Cmd - similar to Term, but the state must be saved
>between each cmd
>
>(I know I'm stretching the paradigm a little bit here, probably beyond what
>is reasonable.
Stretching the paradigm can be good. My mind was going along the same
direction -- figuring out an implementation is a bit of a problem at the
moment though.
>One of the primary design rules is to *not* fall into the "least common
>denominator"
>trap. Many cross-platform application frameworks have done this and failed.
>Rather, the design goal is to *enable* the widget to fully utilize the
>capabilities
>of the technical environment it is in.
Provide a way to query capabilities of the underlying technology -- how big is
the screen, remote vs. local, degree of user interaction available, etc.
--
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix
Re: Real Widgets and Template Languages
On Tue, 29 May 2001, Stephen Adkins wrote:
> Right. I have many more requirements I eventually want to support
> (such as internationalization). The trick is making the design such
> that it works in the simple case for simple things, while supporting
> advanced features for those who wish to use them. I think it is coming
> together pretty well.
I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right off the top. If
my widgets aren't multilingual then I'll have to go elsewhere. 75% of my apps are bi
and trilingual.
I think we should bite the bullet and start talkin Unicode and ISO-639 language codes
right at the beginning.
If a widget has a textual element to be used in rendering (ie/ label) it should have
as many language forms as the developer requires. If a language form is missing it
should kick down to a default language (EN-CA for example - otherwise words like
colour and flavour will be mispelled ;-) ).
Where is this language value coming from? The widget's container. You only care about
English? Then set it to "EN-US" and forget it.
$widget->container->language="EN-CA"
print $widget->label
"What is your favorite flavour of ice cream?"
$widget->container->language="EN-US"
print $widget->label
"What is your favorite flavor of ice cream?"
$widget->container->language="FR-CA"
print $widget->label
""
I'm sure you see the pattern.
Not every property should be considered polylingual but ones that contain textual or
language-specific visual elements should be.
Implementation strategies can be as simple as:
sub label {
my $self=shift;
my $lang=shift || $self->container->language;
if (exists $self->{'label'}{$lang}) {
return $self->{'label'}{$lang};
}
return $self->{'label'}{$self->container->language('default');
}
My personal strategy to date is to create meta data describing the class in general.
Accessor functions for properties are created dynamically via AUTOLOAD mechanism.
Based on metadata for class in question the AUTOLOADer will setup the accessor using
one of a few different behaviors.
In closing - although it seems like a drag in the beginning - it really makes sense to
develop applications and components to support multiple languages. It is a zillion
times more difficult to cobble in the fucntionality after the fact.
Jay
Re: Real Widgets and Template Languages
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
Re: Real Widgets and Template Languages
At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote:
>At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote:
...
>>$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.
This is a philosophical design decision that I have been struggling with.
The widget does indeed know that it should generate HTML, so it could have
a method, $widget->display(), $widget->draw(), etc.
However, this implies that the widget has the freedom to decide how it
should render itself and that the caller does not need to know.
This is not correct.
The caller in this case has already cooked up a bunch of HTML and is
counting on the widget to produce HTML which can be inserted.
The widget does *not* have the freedom to render any other way.
This is why I have (sort of stubbornly) stuck with the $widget->html()
method despite the unanimous suggestions for a $widget->display()
method.
I do believe there is a place for a display() method, but it is at
the controller level. The is the level at which the caller may not
know what technologies are being used by the widgets.
This whole discussion brings out two other important design decisions.
1. What are the UI technologies we really wish to support?
(i.e. is this *really* a Widget or an HTML::Widget library?)
2. Which classes represent Logical Widgets and which Physical Widgets?
1. TECHNOLOGIES
I propose that the following technologies will have supporting
Controller/State/Widget combinations to make this not just another web
widget library.
* CGI/HTML - a web application
* mod_perl/HTML - similar, a web application using mod_perl
* WAP/WML - driven from a WAP device
* X11 (Gtk-Perl)- an X windows application
* Curses (terminal) - a screen-oriented terminal application
* Term - a line-oriented (scrolling) terminal application
* Cmd - similar to Term, but the state must be saved
between each cmd
(I know I'm stretching the paradigm a little bit here, probably beyond what
is reasonable.
If you don't think one or more of these is a good idea, please keep it to
yourself.
I have a vision for it, and even if it's not very useful, it will shape the
"abstractness"
of the design elements. On the other hand, I would welcome suggestions for
additional
UI technologies that I might consider supporting.)
One of the primary design rules is to *not* fall into the "least common
denominator"
trap. Many cross-platform application frameworks have done this and failed.
Rather, the design goal is to *enable* the widget to fully utilize the
capabilities
of the technical environment it is in.
This brings me to the next topic.
2. LOGICAL vs. PHYSICAL USER INTERFACE ELEMENTS
I have spoken about the separation of the logical and physical user interface.
This facilitates applications being written to the logical interface.
The physical UI is then determined at a combination of configuration-time
(config file) and run-time (user preferences, browser capabilities, etc.).
As the library has developed, it has become clear that the "logical UI"
is really only a figment of the coder's imagination, represented by code like
$widget = $wc->widget("file_name");
However, the Widget::Controller ($wc) decides (based on config and runtime
values)
which *physical* UI widget is returned. This could be a drop-down list box
(),
a text box, a set of radio buttons, or some sort of complex/compound file
chooser widget.
So when you code a widget, it is a physical widget. The selection between
physical
widgets in order to fulfill the requirements of the logical widget are all
decided
by the Widget::Controller. Similarly if the Controller is a CGI/mod_perl
Controller,
it will only choose HTML widgets, whereas if the Controller is a WAP
Controller,
it would only choose WML widgets, etc.
Note: This allows you to write physical widgets which are tied intimately with
a particular browser version. The Controller and Config mechanism would
*allow*
you (not force you) to write an application that falls back gracefully and
uses
other physical widgets for different browsers. A "Menu" widget using all
sorts
of whiz-bang DHTML on IE 5.0 could be rendered sanely using a different visual
paradigm on an NS 2.0 browser (or Lynx, or Curses!) using a different
physical
widget.
This brings us back to the debate over the display() method vs. the html()
method.
Every widget class only runs in a certain environment.
An HTML widget is being told to emit HTML, hence the method name "html()".
In addition, the display() method really does not display anything.
It simply returns HTML. It is only displayed whe
Re: Real Widgets and Template Languages
Gunther Birznieks <[EMAIL PROTECTED]> wrote: >At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote: >>The rendering of this widget as HTML requires at least the following >> >>* config information (Widget::Config) [snip] >> >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? >> >>Configuration data is read in via the Widget::Config class, and this class can >>be replaced with a class which reads config data from any other source, as >>long as >>it conforms to the same calling interface. >> >>I was under the impression that XML was your desired means of writing a >>config file. >>Do you have a preference to use something different? > >I like XML for Config files, we use that in our Java stuff all the time. >But Perl is one of the nicest and flexible config file languages out there. >IE My config file is Perl. > >Anyway, I think it is weird to think of configuring just widgets. Usually >you configure an application and widgets are a part of that. But everyone >here will have a different way of preferring to write their application >config whether it's XML or Perl and what features of these that are used >(eg just a set of scalars or references to hashes or ... ?) or in the case >of XML using attributes versus subtags... 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. 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. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: Real Widgets and Template Languages
At 05:27 PM 5/29/2001 +0200, Issac Goldstand wrote: > >> 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. > >Actually, I personally think that you're both correct here - I think the >proper way to stash the widgets would be through Storable. If you wish to >do it through XML, then that should call for an extension to Storable which >can store/retrieve data from XML. > > Issac I completely understand what all three of you are saying, and I think the needs of the Gunther and Jay are being accommodated in the new design. However, a note on XML and Storable ... The XML::Simple class allows you a "cache" option (which I am using) where it caches the perl data structure in a Storable. The XML::Simple class reads the XML file into a perl data structure, then stores it as a Storable. On subsequent reads, it checks the timestamps of the .xml file and the .stor file and only rereads the XML file if it is newer than the .stor file. Otherwise, it just reads the .stor file. This appears to be about 3x faster. It would be kind of interesting if the Storable class were extended to store as XML ... ;-) Stephen
Re: Real Widgets and Template Languages
At 9:53 PM +0800 5/29/01, Gunther Birznieks wrote:
>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
>>::
>>
>> >maxlength='99'/>
>> >tag='input' type='text' size='14' maxlength='99'/>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>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.
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 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.
>>::
>>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.
What about draw? display might be misinterpreted. If I draw
something, does that mean I've displayed it? Under the Xwindow
system, widgets are drawn and then shown, IIRC...
print "First Name: ", $widget->draw(),"\n";
Robert Landrum
--
As soon as you make something foolproof, someone will create a better fool.
Re: Real Widgets and Template Languages
> 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. Actually, I personally think that you're both correct here - I think the proper way to stash the widgets would be through Storable. If you wish to do it through XML, then that should call for an extension to Storable which can store/retrieve data from XML. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: Real Widgets and Template Languages
At 09:49 PM 5/29/2001 +0800, Gunther Birznieks wrote:
>At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote:
>>Hi,
>>
>>Development of a straw-man set of Perl Widget Library core classes is
>>going well. A Sourceforge project (perl-widget) is in the process of being
>>set up too. (I will announce when it is set up.)
...
>>The state information can be accessed from *any* source by implementing an
>>appropriate
>>WidgetState class (and using some additional,
>>not-yet-implemented arguments
>>to Widget->controller()).
>
>I think it would be better as a Widget::State:: rather than the
>other way around. From the way you describe it, this is really an interface
>to getting state information that should be retrieved from a DataSource
>specific state driver.
I have come to the same conclusion.
I am changing the design to have three core base classes (other than the
widgets):
Widget::Controller
Widget::Config
Widget::State
A CGI program might run with the following derived classes:
(These are the initial defaults I am working on.)
Widget::Controller::CGI
Widget::Config::XML
Widget::State::CGI
All of these "drivers" may be overridden, as long as the driver you replace it
with conforms to the interface definition described by the core base classes.
(Kind of like a Java interface. You would be encouraged to derive from the
core base classes, but that is not necessary.)
...
>> >
>> >I don't understand the Widget::Controller. Can you say more about this?
>>
>>The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
>>container class
>>that you spoke about in your original post. I call it a Controller rather
>>than
>>a Container because I envision it being able to dispatch events generated
>>by the
>>widgets.
>
>Ah. I just want something to contain the widgets essentially. So perhaps
>from my perspective events aren't necessary and I would potentially just
>place the widgets into an array representing my HTML screen.
>
I have found that event handling comes in surprisingly handy even for
simple tasks.
Essentially, it allows widgets to define callbacks.
For instance, the DateDropDowns widget defines an event "change"
(modelled after the Javascript "onChange" event) that, when triggered,
concatenates
the , MM, and DD back into -MM-DD.
The following is working code.
Notice that the "$wc->dispatch_events($query);" statement takes care of
whatever widget housecleaning there may be (in this case, recomposing the date
as a single variable from the three drop-downs).
::
cgisample
::
#!/usr/local/bin/perl -w
##
# cgisample
##
# This is an example of a CGI script that uses the capabilities
# of the Perl Widget Library minimally.
# It looks like any other perl script which uses the CGI.pm
# library.
# See 'wexec' for an example of a CGI script that uses
# the full capabilities of the Perl Widget Library.
##
use lib "/usr/ov/acoc/dev/src/Widget";
use CGI;
$query = new CGI;
use Widget;
$wc = Widget->controller();
$wc->dispatch_events($query);
print <
cgisample
cgisample
EOF
$anniv_dt = $wc->widget("anniv_dt");
$button = $wc->widget("check_it");
print "Anniversary Date: ", $anniv_dt->html(), "\n";
print $button->html(), "\n";
print "Your anniversary date appears to be: ",
$anniv_dt->value("anniv_dt"), "\n";
print <
>> >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?
>>
>>Configuration data is read in via the Widget::Config class, and this
class can
>>be replaced with a class which reads config data from any other source, as
>>long as
>>it conforms to the same calling interface.
>>
>>I was under the impression that XML was your desired means of writing a
>>config file.
>>Do you have a preference to use something different?
>
>I like XML for Config files, we use that in our Java stuff all the time.
>But Perl is one of the nicest and flexible config file languages out there.
>IE My config file is Perl.
>
>Anyway, I think it is weird to think of configuring just widgets. Usually
>you configure an application and widgets are a part of that. But everyone
>here will have a different way of preferring to write their application
>config whether it's XML or Perl and what features of these that are used
>(eg just a set of scalars or references to hashes or ... ?) or in the case
>of XML using attributes versus subtags...
I had the hunch that everyone's configuration needs would be different.
Hence the Widget::Config (interface) and Widget::Config::XML (driver)
design. (Thanks for the input.)
>I am not quite sure that the configuration is so extensive for each
>individual widget that it can't be done by having a named parameter
>constructor similar to that handled b
Re: Real Widgets and Template Languages
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
> >::
> >
> >>maxlength='99'/>
> >>tag='input' type='text' size='14' maxlength='99'/>
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> 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
>
>
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
>::
>
> maxlength='99'/>
> tag='input' type='text' size='14' maxlength='99'/>
>
>
>
>
>
>
>
>
>
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
Re: Real Widgets and Template Languages
At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote:
>Hi,
>
>Development of a straw-man set of Perl Widget Library core classes is
>going well. A Sourceforge project (perl-widget) is in the process of being
>set up too. (I will announce when it is set up.)
>
>The first 0.01 release will be for public comment on
>the structure and concepts of the core classes.
>
>With regard to all of the debate on closures/classes/etc., let me say that
>I intend for the PWL to be useful in a variety of environments with
>different people using more or less of the features.
>I am favoring flexibility over performance at the moment, so full classes
>are being used to access the different features of the different systems
>with which it will need to interface.
I think this makes sense. I would like to see the model worked out well
before eeking out the performance.
>At the low end, the PWL will support the simple use that Gunther requires:
>simple generation of HTML of a named widget based on configuration
>information.
Thanks. :)
>At the high end, Jay Lawrence and I envision much more sophisticated
>features ...
>but let's not let the consideration of those get in the way of
>accomplishing our
>first task as described above.
>
>A Template Toolkit user should be able to say
>
>[%PERL%]
> use Widget;
> $stash->{wc} = Widget->controller();
>[%END%]
>
>Birth Date: [% wc.widget("birth_date") %]
>
>or eventually something simpler like
>
>[% USE wc = Widget %]
>
>Birth Date: [% wc.birth_date %]
>
>and the appropriately configured HTML will be inserted.
>For non-users of Template Toolkit, they can do the comparable perl ...
>
>use Widget;
>$wc = Widget->controller();
>$widget = $wc->widget("birth_dt");
>print "Birth Date: ", $widget->html(), "\n";
I think this seems reasonable.
>The rendering of this widget as HTML requires at least the following
>
>* config information (Widget::Config)
I'll talk about config in a bit.
>* state information (to get the current value) (Widget::CGI::State in a
>CGI environment)
>
>The state information can be accessed from *any* source by implementing an
>appropriate
>WidgetState class (and using some additional,
>not-yet-implemented arguments
>to Widget->controller()).
I think it would be better as a Widget::State:: rather than the
other way around. From the way you describe it, this is really an interface
to getting state information that should be retrieved from a DataSource
specific state driver.
>see below for more comments ...
>
>At 11:10 PM 5/28/2001 +0800, Gunther Birznieks wrote:
> >At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote:
> >...
> >>I have done the Widget.pm convenience functions and factory code.
> >>I am working on the Widget::Config class to read XML config data using
> >>XML::Simple.
> >>Then on to Widget::Base a parent class for all implemented widgets.
> >>Then on to Widget::Controller which will be handed a CGI object
> >>(or Apache::Request or whatever using one of the much-commented on schemes)
> >>and dispatches events detected from submit buttons, etc.
> >>Then I do my first actual widget, Widget::HTML::Date.
> >>I'll camp on this while I get lots of feedback.
> >
> >I don't understand the Widget::Controller. Can you say more about this?
>
>The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
>container class
>that you spoke about in your original post. I call it a Controller rather
>than
>a Container because I envision it being able to dispatch events generated
>by the
>widgets.
Ah. I just want something to contain the widgets essentially. So perhaps
from my perspective events aren't necessary and I would potentially just
place the widgets into an array representing my HTML screen.
> >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?
>
>Configuration data is read in via the Widget::Config class, and this class can
>be replaced with a class which reads config data from any other source, as
>long as
>it conforms to the same calling interface.
>
>I was under the impression that XML was your desired means of writing a
>config file.
>Do you have a preference to use something different?
I like XML for Config files, we use that in our Java stuff all the time.
But Perl is one of the nicest and flexible config file languages out there.
IE My config file is Perl.
Anyway, I think it is weird to think of configuring just widgets. Usually
you configure an application and widgets are a part of that. But everyone
here will have a different way of preferring to write their application
config whether it's XML or Perl and what features of these that are used
(eg just a set of scalars or references to hashes or ... ?) or in the case
of XML using attributes versus subtags...
I am not quite sure that the configuration is so extensive for each
individual widget that it can't be done by having
Re: Real Widgets and Template Languages
> Let's focus a bit. Specifically on requirements more than implementation - *GOOD* > All I (just my opinion) really want is a widget library for is to get and > set data in a widget and have the widget subclass know how to display > itself. In addition, there should be some mechanism for specifying how the > widget sets up it's internal state based on CGI.pm, Apache::Request, > Session data or what have you. Could I paraphrase or reinterpret what you have said to be base classes for handling widget properties and data sources? In the web world I see data coming from: static widget properties - design/configuration values user supplied values - Session and Request values data sources - RDBMS, LDAP, yadda In addition I do see a variety of flavours for this data: scalar, array, hash. Me, I want even more exotic flavours such as language sensitive (The lable property check's user's language choice and will give them back the lable in the right language). In order for a widget set to be useful we have to agree on how to pass around a certain set of potentially complex data types. READ: robust base object class with potentially fancy strategy for rationalizing a number of data sources and data structures. Additionally - when it comes to widget-specific actions - such as rendering, then you're seeing this as a subclass (or group of methods) that has been defined by the widget creator. ie/ widget->render - generic method that checks container and calls appropriate render subclass for this widget since container is HTML return widget->render_HTML or whatever. READ: object hierarchy. Objects check their parents for hints on how to do things - like pick the form to render themselves, etc. > 1. Data Validation logic. No, this does not belong there. This is a > separate library. I already have a rich Data handling library in my toolkit > that I intend to plug widgets into. All I need is to be able to get widget > data from the data handling/validation library. If I place a widget into my user interface and allow a user to specify a value how I am I to implement validation? ie/ Widget has property "choice" which can be "1","2", or "3". If the user supplies any other value I want choice to be NULL and raise an error. A - does controlling application logic enforce choice validation B - does widget have property information to say that choice property must pass some validation process? I like B because it further compartmentalizes the behaviors of the widget within its own specification. The source of the valication routines can be external to the widget and classes but the validation rules would be specified within here. > 2. External display stuff. No, I just want the widget to know how to draw > itself and only itself. It's up to a template language plugin like TT or > some other template language to provide the wrappings. Or it can be a > toolkit like your drawing forms library -- but the widget itself shouldn't > have to know about external decoration around it. Just how to draw itself. If one is to create an HTML form on a web page then all of the form elements should actually be contained within in a FORM container. The FORM container can then facillitate the correct development of HTML etc. If the widgets are used within another context then the FORM container might be necessary or it might not. But it is usually easier to ignore than try to backpeddle and whack stuff in after its kinda too late. > It's possible, but I am not quite sure because the primary complexity seems > to be the data handling (which I have already in a separate abstraction) > and the UI generation which I have already in Template Toolkit. So all I > really want is an object abstract called a Widget along with a > WidgetCollection to allow grouping widgets together that belong on a given > HTML page. The way I am seeing a solution come together is somewhat different. First of all I am now tending to really really really want to work with persistant object collections. As my application needs new widgets I instanciate a new object of that class into the app's collection of objects. Then I can set its properties as I wish. From that point onwards I can just boss the widgets around and make 'em do what I want. If you do not want to work with persistent object system then you can come up with any number of tactics to define your widget objects as needed: XML, inline code, Data::Dumper, etc. A few of my thoughts, Jay
Re: Real Widgets and Template Languages
>
>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
::
::
Widget.2
::
#!/usr/local/bin/perl
use lib "..";
use Widget;
my ($wc, $widget, @widgets);
$wc = Widget->controller();
$widget = $wc->widget("first_name");
print "First Name: ", $widget->html(), "\n";
$widget = $wc->widget("last_name");
print "Last Name: ", $widget->html(), "\n";
$widget = $wc->widget("birth_dt");
print "Birth Date: ", $widget->html(), "\n";
$widget = $wc->widget("sex");
print "Sex: ", $widget->html(), "\n";
shark:/usr/ov/acoc/dev/src/Widget/examples> Widget.2
First Name:
Last Name:
Birth Date:
Sex:
Male
Female
Re: Real Widgets and Template Languages
Hi,
Development of a straw-man set of Perl Widget Library core classes is
going well. A Sourceforge project (perl-widget) is in the process of being
set up too. (I will announce when it is set up.)
The first 0.01 release will be for public comment on
the structure and concepts of the core classes.
With regard to all of the debate on closures/classes/etc., let me say that
I intend for the PWL to be useful in a variety of environments with
different people using more or less of the features.
I am favoring flexibility over performance at the moment, so full classes
are being used to access the different features of the different systems
with which it will need to interface.
At the low end, the PWL will support the simple use that Gunther requires:
simple generation of HTML of a named widget based on configuration
information.
At the high end, Jay Lawrence and I envision much more sophisticated
features ...
but let's not let the consideration of those get in the way of
accomplishing our
first task as described above.
A Template Toolkit user should be able to say
[%PERL%]
use Widget;
$stash->{wc} = Widget->controller();
[%END%]
Birth Date: [% wc.widget("birth_date") %]
or eventually something simpler like
[% USE wc = Widget %]
Birth Date: [% wc.birth_date %]
and the appropriately configured HTML will be inserted.
For non-users of Template Toolkit, they can do the comparable perl ...
use Widget;
$wc = Widget->controller();
$widget = $wc->widget("birth_dt");
print "Birth Date: ", $widget->html(), "\n";
The rendering of this widget as HTML requires at least the following
* config information (Widget::Config)
* state information (to get the current value) (Widget::CGI::State in a
CGI environment)
The state information can be accessed from *any* source by implementing an
appropriate
WidgetState class (and using some additional,
not-yet-implemented arguments
to Widget->controller()).
see below for more comments ...
At 11:10 PM 5/28/2001 +0800, Gunther Birznieks wrote:
>At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote:
>...
>>I have done the Widget.pm convenience functions and factory code.
>>I am working on the Widget::Config class to read XML config data using
>>XML::Simple.
>>Then on to Widget::Base a parent class for all implemented widgets.
>>Then on to Widget::Controller which will be handed a CGI object
>>(or Apache::Request or whatever using one of the much-commented on schemes)
>>and dispatches events detected from submit buttons, etc.
>>Then I do my first actual widget, Widget::HTML::Date.
>>I'll camp on this while I get lots of feedback.
>
>I don't understand the Widget::Controller. Can you say more about this?
The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
container class
that you spoke about in your original post. I call it a Controller rather
than
a Container because I envision it being able to dispatch events generated
by the
widgets.
>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?
Configuration data is read in via the Widget::Config class, and this class can
be replaced with a class which reads config data from any other source, as
long as
it conforms to the same calling interface.
I was under the impression that XML was your desired means of writing a
config file.
Do you have a preference to use something different?
>Thanks,
> Gunther
Stephen
Re: Real Widgets and Template Languages
Gunther Birznieks wrote: > The design pattern here is that driver specific stuff goes into a > constructor or config method. But leave the rest of the methods alone. This > allows you to plug and play the objects. I like that. Every time the idea of widgets (small w) comes up, my mind wanders back to UIML [1]. In a nutshell, UIML tries to define a simple markup syntax for making device/language-agnostic user interfaces. So, theoretically, you could build Web, WAP, Tk, etc. applications from the same base document. It may be worth another look in this context. I'm not suggesting, BTW, that Widget::* stuff should be based on UIML (or any other ML du jour) only that it's a bit of prior art relevant to building client/device-neutral UIs that we might be able to borrow from. -kip [1] http://www.uiml.org/specs/uiml2/index.htm -- "Perl was written first of all to let the Artist make amoral decisions." - Larry Wall
Re: Real Widgets and Template Languages
Gunther Birznieks <[EMAIL PROTECTED]> wrote: >At 02:31 AM 5/25/01 -0400, Chip Turner wrote: >>Gunther Birznieks <[EMAIL PROTECTED]> writes: >> >> > However, I think it is reasonable to make the interface to support a >> > data source for the widgets flexible and object based to make it easy >> > for someone to write a DBI source, a DBM source, an LDAP source, an >> > Apache::Session source or whatever anyone wants really. I happen to >> > think DBI and Session sources are cool. >> >>I agree; unfortunately writing classes to interface to all of these >>would be difficult, and it would be difficult to be futureproof. When >>you hit LDAP and DBI you must then worry about databases, tables, >>servers, usernames, passwords, etc. It can become cumbersome to do >>the simple things. > >I disagree. I've written interfaces like this before to LDAP and DBI. The >constructor (or config method) on a data source is stuff like usernames/ >passwords, and in the case of LDAP, schema mappings. Hmm... Something I'd like to see is a set of classes in Perl for managing LDAP. These classes would need to be generic (configurable) enough to work with any LDAP schema. They would need to provide an audit trail, transaction log, etc., that could be used to replay changes made to LDAP. They would need to be able to enforce data consistancy across branches and data integrity. If noone gets to it before I do, I'll port my PHP code to Perl :) Oh, and locking mechanisms used must be transferable between machines -- I lock resource A on machine X and then hand off the lock to machine Y -- this code must be useful in a distributed environment (web farm) and robust enough for use in a PKI. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: Real Widgets and Template Languages
At 02:31 AM 5/25/01 -0400, Chip Turner wrote: >Gunther Birznieks <[EMAIL PROTECTED]> writes: > > > However, I think it is reasonable to make the interface to support a > > data source for the widgets flexible and object based to make it easy > > for someone to write a DBI source, a DBM source, an LDAP source, an > > Apache::Session source or whatever anyone wants really. I happen to > > think DBI and Session sources are cool. > >I agree; unfortunately writing classes to interface to all of these >would be difficult, and it would be difficult to be futureproof. When >you hit LDAP and DBI you must then worry about databases, tables, >servers, usernames, passwords, etc. It can become cumbersome to do >the simple things. I disagree. I've written interfaces like this before to LDAP and DBI. The constructor (or config method) on a data source is stuff like usernames/ passwords, and in the case of LDAP, schema mappings. As long as the actual methods for getting and setting the data are the same, you just can get away with making the constructor for the data source the place where you define all this driver specific stuff. The design pattern here is that driver specific stuff goes into a constructor or config method. But leave the rest of the methods alone. This allows you to plug and play the objects.
Re: Real Widgets and Template Languages
At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote: >Jay, > >I think that pretty much describes what I have in mind ... >plus a few other features. > >Hopefully within a week or two (based on demands of other *paying* jobs), >I will have a working distribution with most of the bare-bones plumbing in >place and a little configurable date widget implemented. > >This will allow me to solicit feedback on the plumbing and concepts >before I go hog wild on implementing a host of widgets. >(In fact, I predict the package will be downright boring for a month or more, >to those who don't want to shape its development, while I get the >concept and the internals right.) > >I have done the Widget.pm convenience functions and factory code. >I am working on the Widget::Config class to read XML config data using >XML::Simple. >Then on to Widget::Base a parent class for all implemented widgets. >Then on to Widget::Controller which will be handed a CGI object >(or Apache::Request or whatever using one of the much-commented on schemes) >and dispatches events detected from submit buttons, etc. >Then I do my first actual widget, Widget::HTML::Date. >I'll camp on this while I get lots of feedback. 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? Thanks, Gunther
Re: Real Widgets and Template Languages
I think this post is quite apt. At 02:12 AM 5/25/01 -0400, Chip Turner wrote: >Gunther Birznieks <[EMAIL PROTECTED]> writes: > > > While I think that it is clever to allow an interface to change where > > the parameters come from, I think in practice there are different > > things to expect. eg how to deal with multi-values? How to deal with > > file upload field? I think there are quirks in various libraries. > >Indeed, these are open questions that aren't dealt with so easily with >a closure. But I think for a general widget set, a closure would >work. If you want to get really tricky, you can bless the >closure... but at that point, you should just be using a class in the >first place. > > > I do not think these things are insurmountable. And Chip's suggestion > > stands a good chance of working. I do also think there are so few > > libraries to deal with parameters that it would not be an unreasonable > > design decision to make the Widget controller hard code knowledge of > > CGI.pm, Apache::Request and any others since there really aren't many. > >I disagree here; Mason, Apache::ASP, embperl, straight modperl, >CGI.pm, the various CGI accelerators, etc, are a variety of >interfaces. Anytime you have an application framework (or whatever >they're called this week), you can have a different interface to even >the simplest of things like form variables. > >Another nice thing about not requiring CGI.pm or libapreq is you can >actually feed the formvars from something besides an HTTP submission >(useful for page generation into flat html, or for testing). > > > Likewise, we might consider that CGI.pm is the primary source of > > information, but if I pass a db record set to the widget controller > > along with CGI.pm, I may want CGI.pm to override the database but if > > there is no CGI.pm value, then the value from the database field will > > be placed in the widget instead. > > > > Anyway, I am sorry if this sounds quite odd. I am not good at > > explaining things when I am tired, but I did at least want to throw > > out the idea of not being married yet to a particular way of having a > > widget consume data from a data source. > >I agree that there are a lot of various issues here for when it comes >to handling data input and output. But I think that for something >like a Widget set to be useful, it needs to be as decoupled as >possible from all external libraries, and still be able to play with >them. Now, that means one of two things. > >(a) Some kind of base class (Some people suggest using an "implied" >interface without a true abstract base class that defines the various >methods; I am very much against this because it can lead to somewhat >sloppy programming. If you're going to use objects, use them in a way >that other languages tend to use them and not as typeless chunks that >respond to various kinds of black magic poking and prodding). I >personally only see this being not-the-best-option because of >unnecessary complexity for the fairly simple task at hand. If the >task were more complicated, there is no doubt this is the proper >route. > >(b) The other option, a closure, makes the simple things simple, but >the harder things a bit harder. File uploads, for instance, and >cookies. Of course, since a Widget set rarely (if ever) would need to >display the content of an upload as part of a re-rendering of the >widget, I don't see this being a common use. Likewise, cookies don't >seem as needed to be for more or less the same reason (if you're using >raw cookies to pass complex data around, you're probably doing more >work than you need to; things like Apache::Session make life easier >without forcing you to muck with cookies at every data access point). > >It gets ugly though if you -do- want cookies. Does your abstract base >class (ABT) have to be typed for every possible pair of form var >input and cookie input methods? Is there a separate interface for >each, thus complicating the API slightly? > >The more I think about it, the more wrong it seems for the Widget >library to assume anything about where its data is coming from. It >should either be from a closure or a class based on an ABT. A third >option is that all widgets are actually generated by a generator >instance of a class; this could simplify the API so that you needn't >pass the CGI object or closure around all the time. In this case, you >could derive from this base class to create new ways of gathering data >from CGI and cookies. > >This is more or less a standard design pattern -- data interfacing. >There are a number of solutions. I just hope whatever gets written is >present and future proof enough to not depend on any particular >interface (such as CGI or libapreq), or at the very least made to >easily use others. You never know when someone else may have another >templating technology that has a different interface! I think your post makes a lot of sense. How about this as a simple proposal. Widgets s
RE: Real Widgets and Template Languages [resend]
I read this post a few times.
At 03:44 PM 5/24/01 -0400, David Harris wrote:
>[[ This is a resend.. did some cutting and pasting of code into telnet
>windows that messed it up through shell expansion. My bad. ]]
>
>I have a couple modules that might be the start of what you are calling a
>Widget system. I'm not sure if my modules are in line with the thoughts
>expressed on this list. Pardon me if this is something different: I've been
>loosely following this discussion..
>
>Using my library, whenever I want a form I specify in one list all of the
>elements along with the type of data and any validation routines. Some
>information about how the form should look is also included. My code then
>automatically generates the form (it looks like a dialogue box) from this
>information. The same informational hash is used to parse the form and
>validate the data. If the data is not validated correctly, the form is shown
>again with the validation errors and the data remaining sticky. If the data
>is validated then it is returned in a hash.
I think this is reasonable and correct direction and its good that you've
functionally broken the pieces down.
But the syntax feels like you are wrapping up too many things at once.
We don't really want to define any HTML for the individual widgets. Nor
should the widgets know how to validate themselves. Nor should the widgets
know how to draw stuff around themselves like tables.
>Here is a simplified example of the widget definitions for a form that
>allows a customer to charge money on their credit card into their balance:
>
>[
> amount => { width => "20", same_line => 1,
> label => "Amount to charge (in dollars)", _label => "Amount to
>charge",
> _looks_like => "number", _required => 1, },
>
> [{ addl_require => [{
> type => "sub",
> fields => [qw(amount)],
> sub => sub {
> my ($require, $values, $labels) = @_;
> return "You may not initiate a charge for less than \$5.00."
> if ( $values->[0] < 5 );
> return "You may not initiate a charge for more than \$900.00. If
>you really do want to
> charge this much, then you need to call us and we can do it
>for you."
> if ( $values->[0] > 900 );
> return undef;
> },
> }], }],
>]
"Simplified". :)
Well, while I think this is interesting, it is too much for a widget
library. I think this is fairly clear from the examples.
Let's focus a bit.
All I (just my opinion) really want is a widget library for is to get and
set data in a widget and have the widget subclass know how to display
itself. In addition, there should be some mechanism for specifying how the
widget sets up it's internal state based on CGI.pm, Apache::Request,
Session data or what have you.
1. Data Validation logic. No, this does not belong there. This is a
separate library. I already have a rich Data handling library in my toolkit
that I intend to plug widgets into. All I need is to be able to get widget
data from the data handling/validation library.
2. External display stuff. No, I just want the widget to know how to draw
itself and only itself. It's up to a template language plugin like TT or
some other template language to provide the wrappings. Or it can be a
toolkit like your drawing forms library -- but the widget itself shouldn't
have to know about external decoration around it. Just how to draw itself.
>This above code is showing the strains of evolution of my system. :-) Notice
I don't think it is a strain on the evolution, just that you attempt to
combine many different concepts together. I think it's too much. You can
abstract away some of these things as noted above.
>This really calls for the widgets to be embedded directly in the HTML
>template which contains the formatting a la that
>Gunther proposed.
Yes, but the widgets I propose could also go into a form builder functions
like the ones you laid out as well. The widgets are supposed to be flexible
to suit any template needs not just TT.
>This above code actually sits in a subroutine that returns a list of the
>definitional information. This list is then simply included other places so
>I can write stuff like this:
>
>[
> [qq[
> Enter your billing information and credit card.
> ]],
>
> [qq[ Billing information ]],
>
> [{ default_by_name => CUST::DbAccess::Cust::default_by_name("custs") }],
>
> CUST::InterfaceUtil::opensrs_contact_fields($country_select_box, "bill",
>"Billing"),
> undef,
>
> [qq[ Credit card information ]],
>
> [{ default_by_name => CUST::DbAccess::Ccard::default_by_name("ccards") }],
>
> CUST::InterfaceUtil::credit_card_fields(),
> undef,
>]
>
>It's great for reuse.
>
>The default_by_name does something interesting: it imports all the defaults
>for the fields (_looks_like and _required and _size) information from the
>database table. If I change the size of a text field in a table all the
>forms which us
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote: > Stas Bekman <[EMAIL PROTECTED]> writes: > > > > You can have the checks in during development, and pull during > > > production. It's not 100% efficient, but it's pretty close. With > > > some use constant magic, you may even be able to get the compiler to > > > optimize away the entire line at compile time, resulting not even in a > > > check on the value of $DEBUG in production environments. > > > > which is true only if it's: > > > > use constant DEBUG => 1; > > > > and not: > > > > $DEBUG = 1; > > Right; hence my veiled reference to 'use constant' magic :) oops, sorry, I didn't mean to say you had a bad suggestion. I was just trying to stress that $DEBUG is bad, since quite a few people will think that if they use $DEBUG it makes things magical, if they don't really know about 'constant' pragma (or just simple subroutine). > > Basically you should be able to turn the development checking at compile > > time for the whole project via startup.pl: > > > > use My::Init qw(PRODUCTION); > > vs. > > use My::Init qw(DEVELOPMENT); > > I like this method of turning debug on and off. Hadn't seen this > novel method, but it has a nice feel to it. Heh, I "invented" it while responding to your email. And I like it too :) In fact I should start using it right away. I think Damian Convey uses this sort of technique in his Class::Contract, so I cannot claim the patent :) > > To conclude, if you make all your checkings/validations only in debug > > version it doesn't matter how fast or slow they are. I think what matters > > here is the clearness of the code. > > I agree 100%. I even think that in some cases it might be useful to write a whole Validation module, to have the code as little cluttered as possible with validation code. Since it'll be stripped away at compile time on production server, there is no fear to have validation functions as methods for example. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Real Widgets and Template Languages
Stas Bekman <[EMAIL PROTECTED]> writes: > > You can have the checks in during development, and pull during > > production. It's not 100% efficient, but it's pretty close. With > > some use constant magic, you may even be able to get the compiler to > > optimize away the entire line at compile time, resulting not even in a > > check on the value of $DEBUG in production environments. > > which is true only if it's: > > use constant DEBUG => 1; > > and not: > > $DEBUG = 1; Right; hence my veiled reference to 'use constant' magic :) > Basically you should be able to turn the development checking at compile > time for the whole project via startup.pl: > > use My::Init qw(PRODUCTION); > vs. > use My::Init qw(DEVELOPMENT); I like this method of turning debug on and off. Hadn't seen this novel method, but it has a nice feel to it. > To conclude, if you make all your checkings/validations only in debug > version it doesn't matter how fast or slow they are. I think what matters > here is the clearness of the code. I agree 100%. Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote:
> brian moseley <[EMAIL PROTECTED]> writes:
>
> > you can certainly say "the nth parameter implements
> > interface Foo::Bar", and provide Foo/Bar.pod that describes
> > the interface, and get the exact same benefit.
>
> Of course. But you lose nothing by actually making it an ISA
> relationship; you don't even lose performance. Plus you could do
> something like this:
>
> sub foo {
> my $self = shift;
> my $bar = shift;
>
> $self->die_because_of_bad_bar_parameter
> if $DEBUG and not $bar->isa('SomeBase::Class');
> ...
> }
>
> You can have the checks in during development, and pull during
> production. It's not 100% efficient, but it's pretty close. With
> some use constant magic, you may even be able to get the compiler to
> optimize away the entire line at compile time, resulting not even in a
> check on the value of $DEBUG in production environments.
which is true only if it's:
use constant DEBUG => 1;
and not:
$DEBUG = 1;
Basically you should be able to turn the development checking at compile
time for the whole project via startup.pl:
use My::Init qw(PRODUCTION);
vs.
use My::Init qw(DEVELOPMENT);
where the My::Init::import() method will load and compile all the modules
that are going to be used, but only after My::Config::DEBUG constant is
either set to 0 or 1.
So you don't have to remember to manually modify every module, in fact
none of them. startup.pl time resolution will make things really flexible.
On the other hand under mod_cgi this can be done in the first BEGIN block
of every script that you use (but then it's cumbersome, since you have to
modify all the scripts all the time, and possibly conflict with CVS) but
hey, we are on the mod_perl list :)
To conclude, if you make all your checkings/validations only in debug
version it doesn't matter how fast or slow they are. I think what matters
here is the clearness of the code.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Real Widgets and Template Languages
brian moseley <[EMAIL PROTECTED]> writes:
> you can certainly say "the nth parameter implements
> interface Foo::Bar", and provide Foo/Bar.pod that describes
> the interface, and get the exact same benefit.
Of course. But you lose nothing by actually making it an ISA
relationship; you don't even lose performance. Plus you could do
something like this:
sub foo {
my $self = shift;
my $bar = shift;
$self->die_because_of_bad_bar_parameter
if $DEBUG and not $bar->isa('SomeBase::Class');
...
}
You can have the checks in during development, and pull during
production. It's not 100% efficient, but it's pretty close. With
some use constant magic, you may even be able to get the compiler to
optimize away the entire line at compile time, resulting not even in a
check on the value of $DEBUG in production environments.
> i question the wisdom of relying on a code-level inheritance
> usage to communicate class relationships. isn't that why we
> use class diagrams and pod?
I don't understand why you would rather not have a very simple base
class that defines the interface, and then have an ISA relationship
with it, instead of simply having several classes with no code level
relationship other than supporting the same method calls.
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote: > Code is cleaner if you can say "the nth parameter is > derived from the base class Foo::Bar" as opposed to "the > nth parameter is an object that must support the baz, > blah, foop, and fitz methods that accept parameters in > the following way..." you can certainly say "the nth parameter implements interface Foo::Bar", and provide Foo/Bar.pod that describes the interface, and get the exact same benefit. i question the wisdom of relying on a code-level inheritance usage to communicate class relationships. isn't that why we use class diagrams and pod?
Re: Real Widgets and Template Languages
brian moseley <[EMAIL PROTECTED]> writes:
> > My only objection to this (as I stated in another email) is that
> > it leaves things largely unspecified. It's similar to the old
> > perl problem of passing big hashes around; you assume the data is
> > there, but there's no real way to find out without checking keys
> > and so forth. A simple $foo->isa('Widget::CGIData') can ensure
> > that what you're talking to is at least derived from the right
> > thing. Just because perl would let you call methods on a class
> > not derived from a standard base doesn't mean it's necessarily
> > appropriate. An abstract base class offers little overhead
> > (especially if you override all of the methods) while still giving
> > that little bit of insurance about just what you've been passed.
> > In a library that conceivably could be used by a number of people,
> > such discipline would probably be a nice thing, even if it didn't
> > actually buy anything in terms of performance or features.
>
> so the only reason you'd provide a superclass is to be able to do an
> isa check? in what circumstances do you use this kind of check? do
> you apply it to every argument in every method call? what do you do
> on failure?
Well, not entirely. It's like the difference between using symbolic
references and not using symbolic references. Sure, they work, and
can be powerful, but they can also be obfuscating and a little
obscure. I don't like tossing objects around and expecting them to
adhere to some unknown interface that they aren't derived from. The
only real difference at the code layer is ->isa, but that's not a
large benefit; instead, it's at the design level. Making an abstract
base class is very simple, and there's no performance overhead for a
class to derive from it if it implements all of its own methods (and
one could argue if there -is- common code that can be implemented in
non-abstract base methods then there is even more benefit in having an
abstract base class).
Basically it's "enforcing" a tiny bit of type data in an otherwise
more or less typeless world.
Code is cleaner if you can say "the nth parameter is derived from the
base class Foo::Bar" as opposed to "the nth parameter is an object
that must support the baz, blah, foop, and fitz methods that accept
parameters in the following way..."
> i've been wondering how best to specify interfaces (in the java
> sense) in perl, whether or not to make them classes. possible
> benefits are type checking (as you've noted above) and verification
> of the implementation of methods specified by the interface. altho
> if i could get benefit #2, i wouldn't care about #1, cos i just want
> to be sure that the implementing class (or one of its ancestors)
> declares each of the interface methods. and i want this verification
> at compile time, not runtime.
Well, you could always do something like:
my Foo::Bar $x = shift;
This doesn't really gain anything now, but it makes things a bit
clearer what exactly is going on. Future perl's may optimize this
(right now, if I recall, it only optimizes in the case of
pseudohashes).
Sadly, you'll never really be able to get compile time type
verification in perl (at least, in perl as it stands today). Even the
above syntax is only a promise to perl for possible optimizations and
not a request for perl to enforce the type of whatever shift returns.
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
On 25 May 2001, Chip Turner wrote:
> My only objection to this (as I stated in another email)
> is that it leaves things largely unspecified. It's
> similar to the old perl problem of passing big hashes
> around; you assume the data is there, but there's no
> real way to find out without checking keys and so forth.
> A simple $foo->isa('Widget::CGIData') can ensure that
> what you're talking to is at least derived from the
> right thing. Just because perl would let you call
> methods on a class not derived from a standard base
> doesn't mean it's necessarily appropriate. An abstract
> base class offers little overhead (especially if you
> override all of the methods) while still giving that
> little bit of insurance about just what you've been
> passed. In a library that conceivably could be used by
> a number of people, such discipline would probably be a
> nice thing, even if it didn't actually buy anything in
> terms of performance or features.
so the only reason you'd provide a superclass is to be able
to do an isa check? in what circumstances do you use this
kind of check? do you apply it to every argument in every
method call? what do you do on failure?
i've been wondering how best to specify interfaces (in the
java sense) in perl, whether or not to make them classes.
possible benefits are type checking (as you've noted above)
and verification of the implementation of methods specified
by the interface. altho if i could get benefit #2, i
wouldn't care about #1, cos i just want to be sure that the
implementing class (or one of its ancestors) declares each
of the interface methods. and i want this verification at
compile time, not runtime.
Re: Real Widgets and Template Languages
Gunther Birznieks <[EMAIL PROTECTED]> writes:
> However, I think it is reasonable to make the interface to support a
> data source for the widgets flexible and object based to make it easy
> for someone to write a DBI source, a DBM source, an LDAP source, an
> Apache::Session source or whatever anyone wants really. I happen to
> think DBI and Session sources are cool.
I agree; unfortunately writing classes to interface to all of these
would be difficult, and it would be difficult to be futureproof. When
you hit LDAP and DBI you must then worry about databases, tables,
servers, usernames, passwords, etc. It can become cumbersome to do
the simple things.
> By default, it could be GPC chaining like PHP (Get, Post,
> Cookie) But with enough widget data sources to choose from you
> could do
>
> GPCSD (Get, Post, Cookie, Session, Database) type of thing.
This can be done quite well from a closure:
my $dbh = DBI->connect(...);
my $sth = $dbh->prepare('SELECT foo FROM persistant_data WHERE id = ?');
my $cgi = new CGI;
my $data_closre =
sub {
my $key = shift;
my $return = $cgi->param($key);
$return = $cgi->cookie($key)
unless defined $return;
if (not defined $return) {
$sth->execute($key);
($return) = $sth->fetchrow;
$sth->finish;
}
return $return;
};
Now the closre, though slightly more complicated, doesn't need to know
anything about the world around it, and neatly cinches off the
interface from Widget into DBI, CGI, cookies, etc etc. Using classes
for this would work, but it could be cumbersome; a closure allows for
near infinite flexibility... but at the price of complexity.
> I think but am not sure that closures likely also have better
> performance than method lookups. If this is the case, it could make
> sense to support a few data sources that need high performance because
> of their common use: CGI.pm and Apache::Request. Yet provide the
> extensibility for other developers to inject their own data sources
> into the chain using an Object-based API.
Closures are indeed faster than both instance method calls and package
method calls. However, this is a very basic thing; if performance is
critical enough to optimize this portion of a program then likely
someone wouldn't be using Widgets anyway :)
> Maybe someone else could comment on the technical merit of closure vs
> objects as well as the way in which they have been expecting the
> widgets to get populated? Is what I am saying make sense?
Below is a script to benchark the various invocations. The baseline
is for a function (method, closure, package method) to take one data
parameter and return something based on it.
The results I get on a dual P3 500 are:
[cturner@magneto cturner]$ perl bench.pl
Benchmark: timing 400 iterations of closure, method, pkgmethod...
closure: 10 wallclock secs ( 9.88 usr + 0.00 sys = 9.88 CPU) @ 404858.30/s
(n=400)
method: 22 wallclock secs (20.98 usr + 0.00 sys = 20.98 CPU) @ 190657.77/s
(n=400)
pkgmethod: 35 wallclock secs (35.59 usr + 0.00 sys = 35.59 CPU) @ 112391.12/s
(n=400)
bench.pl:
#!/usr/bin/perl -w
use strict;
use Benchmark;
my $meth = new Foo;
my $cref = sub { my $data = shift; return 1 };
timethese(400, { 'method' => sub { return $meth->bar },
'closure' => sub { return $cref->() },
'pkgmethod' => sub { return Foo->bar }});
package Foo;
sub new {
return bless {}, shift;
}
sub bar {
my $self = shift;
my $data = shift;
return 1;
}
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
Paul Lindner <[EMAIL PROTECTED]> writes:
> On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote:
> > darren chamberlain <[EMAIL PROTECTED]> writes:
> >
> > The nice thing about closures is they could hide any interface at all
> > behind them; all that is required is that the function that generates
> > the closure follow the very simple convention of "return the formvar
> > of the name starting with the first parameter you're called with."
> > There is absolutely no reliance upon the underlying object structure.
> > What you're suggesting is equivalent to assuming the object is derived
> > from some kind of base class that supports the param() method though
> > without actually having to be ISA of that class. That's naughty OO
> > programming :) Just because perl lets you be typeless doesn't mean
> > it's always in the best interest of clean design to do so.
>
> I don't find a problem with passing an object that has a certain set
> of method signatures. This is functionally loosely equivalent to a
> Java Interface.. Any perl object can implement a particular interface
> just by implementing the methods.. No base class required..
My only objection to this (as I stated in another email) is that it
leaves things largely unspecified. It's similar to the old perl
problem of passing big hashes around; you assume the data is there,
but there's no real way to find out without checking keys and so
forth. A simple $foo->isa('Widget::CGIData') can ensure that what
you're talking to is at least derived from the right thing. Just
because perl would let you call methods on a class not derived from a
standard base doesn't mean it's necessarily appropriate. An abstract
base class offers little overhead (especially if you override all of
the methods) while still giving that little bit of insurance about
just what you've been passed. In a library that conceivably could be
used by a number of people, such discipline would probably be a nice
thing, even if it didn't actually buy anything in terms of performance
or features.
> But I agree, closure are very cool, and allow for an additional layer
> of abstraction between the objects, without having to create a proxy
> class..
Closures are definitely cool. As someone else mentioned, requiring
-all- users of Widgets to use them probably limits the audience,
though, so some level of "smartness" in the Widget system would be
nice; perhaps autogenerating a closure for the things it knows about
(CGI.pm, libapreq, etc).
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
Gunther Birznieks <[EMAIL PROTECTED]> writes: > While I think that it is clever to allow an interface to change where > the parameters come from, I think in practice there are different > things to expect. eg how to deal with multi-values? How to deal with > file upload field? I think there are quirks in various libraries. Indeed, these are open questions that aren't dealt with so easily with a closure. But I think for a general widget set, a closure would work. If you want to get really tricky, you can bless the closure... but at that point, you should just be using a class in the first place. > I do not think these things are insurmountable. And Chip's suggestion > stands a good chance of working. I do also think there are so few > libraries to deal with parameters that it would not be an unreasonable > design decision to make the Widget controller hard code knowledge of > CGI.pm, Apache::Request and any others since there really aren't many. I disagree here; Mason, Apache::ASP, embperl, straight modperl, CGI.pm, the various CGI accelerators, etc, are a variety of interfaces. Anytime you have an application framework (or whatever they're called this week), you can have a different interface to even the simplest of things like form variables. Another nice thing about not requiring CGI.pm or libapreq is you can actually feed the formvars from something besides an HTTP submission (useful for page generation into flat html, or for testing). > Likewise, we might consider that CGI.pm is the primary source of > information, but if I pass a db record set to the widget controller > along with CGI.pm, I may want CGI.pm to override the database but if > there is no CGI.pm value, then the value from the database field will > be placed in the widget instead. > > Anyway, I am sorry if this sounds quite odd. I am not good at > explaining things when I am tired, but I did at least want to throw > out the idea of not being married yet to a particular way of having a > widget consume data from a data source. I agree that there are a lot of various issues here for when it comes to handling data input and output. But I think that for something like a Widget set to be useful, it needs to be as decoupled as possible from all external libraries, and still be able to play with them. Now, that means one of two things. (a) Some kind of base class (Some people suggest using an "implied" interface without a true abstract base class that defines the various methods; I am very much against this because it can lead to somewhat sloppy programming. If you're going to use objects, use them in a way that other languages tend to use them and not as typeless chunks that respond to various kinds of black magic poking and prodding). I personally only see this being not-the-best-option because of unnecessary complexity for the fairly simple task at hand. If the task were more complicated, there is no doubt this is the proper route. (b) The other option, a closure, makes the simple things simple, but the harder things a bit harder. File uploads, for instance, and cookies. Of course, since a Widget set rarely (if ever) would need to display the content of an upload as part of a re-rendering of the widget, I don't see this being a common use. Likewise, cookies don't seem as needed to be for more or less the same reason (if you're using raw cookies to pass complex data around, you're probably doing more work than you need to; things like Apache::Session make life easier without forcing you to muck with cookies at every data access point). It gets ugly though if you -do- want cookies. Does your abstract base class (ABT) have to be typed for every possible pair of form var input and cookie input methods? Is there a separate interface for each, thus complicating the API slightly? The more I think about it, the more wrong it seems for the Widget library to assume anything about where its data is coming from. It should either be from a closure or a class based on an ABT. A third option is that all widgets are actually generated by a generator instance of a class; this could simplify the API so that you needn't pass the CGI object or closure around all the time. In this case, you could derive from this base class to create new ways of gathering data from CGI and cookies. This is more or less a standard design pattern -- data interfacing. There are a number of solutions. I just hope whatever gets written is present and future proof enough to not depend on any particular interface (such as CGI or libapreq), or at the very least made to easily use others. You never know when someone else may have another templating technology that has a different interface! Cheers, Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
Re: Real Widgets and Template Languages
Jay, I think that pretty much describes what I have in mind ... plus a few other features. Hopefully within a week or two (based on demands of other *paying* jobs), I will have a working distribution with most of the bare-bones plumbing in place and a little configurable date widget implemented. This will allow me to solicit feedback on the plumbing and concepts before I go hog wild on implementing a host of widgets. (In fact, I predict the package will be downright boring for a month or more, to those who don't want to shape its development, while I get the concept and the internals right.) I have done the Widget.pm convenience functions and factory code. I am working on the Widget::Config class to read XML config data using XML::Simple. Then on to Widget::Base a parent class for all implemented widgets. Then on to Widget::Controller which will be handed a CGI object (or Apache::Request or whatever using one of the much-commented on schemes) and dispatches events detected from submit buttons, etc. Then I do my first actual widget, Widget::HTML::Date. I'll camp on this while I get lots of feedback. Stephen P.S. I have submitted an application for a Sourceforge project called the "Perl Widget Library". The short name is "perl-widget". I am waiting for approval from Sourceforge. This won't hold me up though. I plan on posting distributions on my web site. At 12:28 PM 5/24/2001 -0400, Jay Lawrence wrote: >Hey all, > >Let me describe what I have been imagining as the ideal widget for what I am >writing: > >1 - it can look to its environment to determine how to render itsself >- am I on an HTML page or something else? >2 - it has properties that can be set and remain static no matter who's >using it >- size, shape, colour, max, min >3 - it has properties that are customized by the individual user of the >widget >- current value, theme choice, >4 - it can tell developers and environments what it can do >- switch_on, switch_off, increment, decrement, etc. >5 - it is capable of persisting from invocation to invocation >- user 1 sets current_value to x - which always comes back for user >1 >6 - it can look to its environment for interhitable properties >- global theme choice, global font, etc. >7 - templating systems know how to call widgets >- because they always use the same method to display themselves >8 - widget can interact with each other >- increasing value on slider widget changes current record # value >for database record widget >9 - access restrctions >- users can override some values but not others >- not everyone can even use this widget, etc. >10 - multilingual >- some things are language neutral others are not - "size" would >probably be neutral whereas "label" would be language sensitive >11 - above all it is easy to use >- ie/ don't make me set a zillion properties just to make it work! > >I am going to throw out a buzzword, gasp, which may serve as a model for >what we are talking about: JavaBeans. I do feel there is a lot of additional >complexity there but it is along the right direction IMHO. > >If you translate my wishlist into technologies I think I am talking about: > >A - a good persistant object management environment >B - user sessions >C - integration of widgets (objects) to user sessions >D - Object API (properties and methods) which are consistant and >predictable >E - self documenting objects > >This is what I have been looking for/writing myself! I am really eager to >chip in on this project and get it going ASAP - but do acknowledge the need >for hearty discussion about what people really want not just my own views. >:)) > >Jay > > > >
Re: Real Widgets and Template Languages
At 10:22 AM 5/24/2001 -0700, Paul Lindner wrote: >On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote: > > darren chamberlain <[EMAIL PROTECTED]> writes: > > > > The nice thing about closures is they could hide any interface at all > > behind them; all that is required is that the function that generates > > the closure follow the very simple convention of "return the formvar > > of the name starting with the first parameter you're called with." > > There is absolutely no reliance upon the underlying object structure. > > What you're suggesting is equivalent to assuming the object is derived > > from some kind of base class that supports the param() method though > > without actually having to be ISA of that class. That's naughty OO > > programming :) Just because perl lets you be typeless doesn't mean > > it's always in the best interest of clean design to do so. > >I don't find a problem with passing an object that has a certain set >of method signatures. This is functionally loosely equivalent to a >Java Interface.. Any perl object can implement a particular interface >just by implementing the methods.. No base class required.. > >But I agree, closure are very cool, and allow for an additional layer >of abstraction between the objects, without having to create a proxy >class.. I think closures would only be cool for performance. I personally do not think it is very intuitive. This is OK if the only things we consider supporting as data sources for the widget are Apache::Request and CGI.pm. However, I think it is reasonable to make the interface to support a data source for the widgets flexible and object based to make it easy for someone to write a DBI source, a DBM source, an LDAP source, an Apache::Session source or whatever anyone wants really. I happen to think DBI and Session sources are cool. This also leads us to the idea of data handlers. We realized early on that model-view-controller doesn't mean just templates because templates only understand OUTPUT part of the view. The INPUT part of the view is just as important and in many cases can be divorced from business logic for most simple validations. This led us to do a data handler architecture (ie http://www.extropia.com/development/webware2/chap12.pdf) The idea of widgets ties very closely into this because just as widgets require a data source to be populated, widgets themselves should have some capability (through get and set methods) to act as a data source themselves. Either to our data handler architecture or... and this is also "cool", to other widgets. It's entirely conceivable that you want the capability of other widgets on the screen to have different defaults based on the values of other widgets. The rules for "chaining" the data sources into a widget could be as simple as that -- chaining. By default, it could be GPC chaining like PHP (Get, Post, Cookie) But with enough widget data sources to choose from you could do GPCSD (Get, Post, Cookie, Session, Database) type of thing. This may sound like an overengineered design, but the reality is that most casual developers will just use GPC like PHP does. It's when you get into more sophisticated requirements for the app that such a thing becomes more useful. This means that the data sources themselves can be accumulated slowly but the interface to support them should be relatively easy. > > Closures are excellent in hiding implementation details of simple > > operations, and I think in this case they fit quite well. The system > > can even be written to work just fine without the user using closures > > if they're using CGI.pm, as in my previous example. I think but am not sure that closures likely also have better performance than method lookups. If this is the case, it could make sense to support a few data sources that need high performance because of their common use: CGI.pm and Apache::Request. Yet provide the extensibility for other developers to inject their own data sources into the chain using an Object-based API. Maybe someone else could comment on the technical merit of closure vs objects as well as the way in which they have been expecting the widgets to get populated? Is what I am saying make sense? Thanks, Gunther
RE: Real Widgets and Template Languages [resend]
[[ This is a resend.. did some cutting and pasting of code into telnet
windows that messed it up through shell expansion. My bad. ]]
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on this list. Pardon me if this is something different: I've been
loosely following this discussion..
Using my library, whenever I want a form I specify in one list all of the
elements along with the type of data and any validation routines. Some
information about how the form should look is also included. My code then
automatically generates the form (it looks like a dialogue box) from this
information. The same informational hash is used to parse the form and
validate the data. If the data is not validated correctly, the form is shown
again with the validation errors and the data remaining sticky. If the data
is validated then it is returned in a hash.
Here is a simplified example of the widget definitions for a form that
allows a customer to charge money on their credit card into their balance:
[
amount => { width => "20", same_line => 1,
label => "Amount to charge (in dollars)", _label => "Amount to
charge",
_looks_like => "number", _required => 1, },
[{ addl_require => [{
type => "sub",
fields => [qw(amount)],
sub => sub {
my ($require, $values, $labels) = @_;
return "You may not initiate a charge for less than \$5.00."
if ( $values->[0] < 5 );
return "You may not initiate a charge for more than \$900.00. If
you really do want to
charge this much, then you need to call us and we can do it
for you."
if ( $values->[0] > 900 );
return undef;
},
}], }],
]
Note the elements "label", "_label", and "same_line" for the "amount" widget
specify display attributes. (My actual definition of the form contains more
than the widgets themselves but rather the whole look and feel form.) The
element "_required" specifies that this widget may not be left blank by the
user. The element "_looks_like" with value "number" specifies that the value
in this text box must be a number. I can also specify dates, free text, or
whatever I needed as types for the widget.
The "addl_require" stuff you see is a way of in lining an additional
requirement: this requires that the value for the amount field must be
between 5.00 and 900.00. The additional requirement is tied specifically to
the fields that it is dependent on. For example, if the field "amount" was
left blank thus not satisfying the "_required" specification, then this
addl_require you see would not be checked, as its dependants has not been
verified.
Here is another example. This is the definition for the form elements to
collect credit card information:
[
[qq[ ]],
card_type => { c_table => 1, et => "select", label => "Card type",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__card_type->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__card_type__keys
],
},
card_num => { c_table => 1, width => 30, label => "Card number" },
[{ addl_require => [{
type => "sub",
fields => [qw(card_num)],
sub => sub {
my ($require, $values, $labels) = @_;
return "The credit card number you entered is not valid."
if ( not Business::CreditCard::validate($values->[0]) );
return undef;
},
}], }],
[qq[ Expiration ]],
exp_month => { c_blank => 1, et => "select", label => "Exp month",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__exp_month->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__exp_month__keys
],
},
[qq[ / ]],
exp_year => { c_blank => 1, et => "select", label => "Exp year",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__exp_year->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__exp_year__keys
],
},
[qq[ ]],
[q[
If the name on the card is different than your billing
address you can enter it below.
]],
card_name => { width => 30, c_table => 1, label => "Name on card" },
[qq[ ]],
]
This above code is showing the strains of evolution of my system. :-) Notice
all the [qq[ ... ]] constructs which allow HTML text to be inlined.
Originally there wasn't much inlined HTML, as each widget knew how to
display itself and its label. However I was stuck to one specific display
look constrained me. So I told the widgets how to print their labels with
"c_blank" and "c_table" parameters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply includ
RE: Real Widgets and Template Languages
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on this list. Pardon me if this is something different: I've been
loosely following this discussion..
Using my library, whenever I want a form I specify in one list all of the
elements along with the type of data and any validation routines. Some
information about how the form should look is also included. My code then
automatically generates the form (it looks like a dialogue box) from this
information. The same informational hash is used to parse the form and
validate the data. If the data is not validated correctly, the form is shown
again with the validation errors and the data remaining sticky. If the data
is validated then it is returned in a hash.
Here is a simplified example of the widget definitions for a form that
allows a customer to charge money on their credit card into their balance:
[
amount => { width => "20", same_line => 1,
label => "Amount to charge (in dollars)", _label => "Amount to
charge",
_looks_like => "number", _required => 1, },
[{ addl_require => [{
type => "sub",
fields => [qw(amount)],
sub => sub {
my ($require, $values, $labels) = @_;
return "You may not initiate a charge for less than \$5.00."
if ( $values->[0] < 5 );
return "You may not initiate a charge for more than \$900.00. If
you really do want to
charge this much, then you need to call us and we can do it
for you."
if ( $values->[0] > 900 );
return undef;
},
}], }],
]
Note the elements "label", "_label", and "same_line" for the "amount" widget
specify display attributes. (My actual definition of the form contains more
than the widgets themselves but rather the whole look and feel form.) The
element "_required" specifies that this widget may not be left blank by the
user. The element "_looks_like" with value "number" specifies that the value
in this text box must be a number. I can also specify dates, free text, or
whatever I needed as types for the widget.
The "addl_require" stuff you see is a way of in lining an additional
requirement: this requires that the value for the amount field must be
between 5.00 and 900.00. The additional requirement is tied specifically to
the fields that it is dependent on. For example, if the field "amount" was
left blank thus not satisfying the "_required" specification, then this
addl_require you see would not be checked, as its dependants has not been
verified.
Here is another example. This is the definition for the form elements to
collect credit card information:
[
[qq[ ]],
card_type => { c_table => 1, et => "select", label => "Card type",
options => [
map { [ ::DbAccess::Lookup::ccard__card_type->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__card_type__keys
],
},
card_num => { c_table => 1, width => 30, label => "Card number" },
[{ addl_require => [{
type => "sub",
fields => [qw(card_num)],
sub => sub {
my (, , ) = @_;
return "The credit card number you entered is not valid."
if ( not Business::CreditCard::validate(->[0]) );
return undef;
},
}], }],
[qq[ Expiration ]],
exp_month => { c_blank => 1, et => "select", label => "Exp month",
options => [
map { [ ::DbAccess::Lookup::ccard__exp_month->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__exp_month__keys
],
},
[qq[ / ]],
exp_year => { c_blank => 1, et => "select", label => "Exp year",
options => [
map { [ ::DbAccess::Lookup::ccard__exp_year->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__exp_year__keys
],
},
[qq[ ]],
[q[
If the name on the card is different than your billing
address you can enter it below.
]],
card_name => { width => 30, c_table => 1, label => "Name on card" },
[qq[ ]],
]
This above code is showing the strains of evolution of my system. :-) Notice
all the [qq[ ... ]] constructs which allow HTML text to be inlined.
Originally there wasn't much inlined HTML, as each widget knew how to
display itself and its label. However I was stuck to one specific display
look constrained me. So I told the widgets how to print their labels with
"c_blank" and "c_table" parameters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply included other places so
I can write stuff like this:
[
[qq[
Enter your billing information and credit card.
]],
[qq[ Billing information ]],
[{ default_b
Re: Real Widgets and Template Languages
On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote: > darren chamberlain <[EMAIL PROTECTED]> writes: > > The nice thing about closures is they could hide any interface at all > behind them; all that is required is that the function that generates > the closure follow the very simple convention of "return the formvar > of the name starting with the first parameter you're called with." > There is absolutely no reliance upon the underlying object structure. > What you're suggesting is equivalent to assuming the object is derived > from some kind of base class that supports the param() method though > without actually having to be ISA of that class. That's naughty OO > programming :) Just because perl lets you be typeless doesn't mean > it's always in the best interest of clean design to do so. I don't find a problem with passing an object that has a certain set of method signatures. This is functionally loosely equivalent to a Java Interface.. Any perl object can implement a particular interface just by implementing the methods.. No base class required.. But I agree, closure are very cool, and allow for an additional layer of abstraction between the objects, without having to create a proxy class.. > Closures are excellent in hiding implementation details of simple > operations, and I think in this case they fit quite well. The system > can even be written to work just fine without the user using closures > if they're using CGI.pm, as in my previous example. -- Paul Lindner [EMAIL PROTECTED]
Re: Real Widgets and Template Languages
Related to the previous discussion of closures vs object interface (eg
param) for getting CGI form data into the widgets:
While I think that it is clever to allow an interface to change where the
parameters come from, I think in practice there are different things to
expect. eg how to deal with multi-values? How to deal with file upload
field? I think there are quirks in various libraries.
I do not think these things are insurmountable. And Chip's suggestion
stands a good chance of working. I do also think there are so few libraries
to deal with parameters that it would not be an unreasonable design
decision to make the Widget controller hard code knowledge of CGI.pm,
Apache::Request and any others since there really aren't many.
At least at first cut. If it looks like there are too many data sources of
widget data to deal with then it has to be dealt with.
I would also offer the possibility that the data source for a widget should
not solely be a CGI.pm object but could conceivably come from many types of
data sources and that these data sources might have priorities yet all
apply to the same widget controller. Let's take a lesson (not necessarily
one to be followed) from PHP. In PHP, variables come into existence
automatically. But there are rules that are followed.
eg Cookies, Get,. Post which means that if the variable is somehow
resulting from a cookie instantiate the var as a the value of the cookie.
If there is a GET param of the same name, override the var with the value
of the Get param, and if there is a POST as well, then override the value
from $ENV{QUERY_STRING} with the value from the POST.
Likewise, we might consider that CGI.pm is the primary source of
information, but if I pass a db record set to the widget controller along
with CGI.pm, I may want CGI.pm to override the database but if there is no
CGI.pm value, then the value from the database field will be placed in the
widget instead.
Anyway, I am sorry if this sounds quite odd. I am not good at explaining
things when I am tired, but I did at least want to throw out the idea of
not being married yet to a particular way of having a widget consume data
from a data source.
Re: Real Widgets and Template Languages
At 08:50 PM 5/23/01 -0400, Adi Fairbank wrote: >Stephen, > >I read your proposal and I like it a lot. I will help filling out the >HTML::Widget::HTML* space (in your package structure suggestion). > >However, I like Gunther's suggestion for a namespace of Widget:: better than >HTML::Widget::, because it will not be exclusively HTML, but WML, JS10, >etc. But either one is fine with me. What is JS10? JavaScript version 1.0? Should we call it JavaScript or EcmaScript? :) I actually think that Perl objects to generate JS validation routines is worthy of its own abstraction. There are several reasons for this. One is that you need to be able to decouple the javascript tags. So if you validate, say, a text field to contain only numbers, the routine to do it should be in the header of the HTML but the widget that gets drawn needs to reference the right routine. So such a library that can generate this stuff needs to be a little more wise and the new JS tags have to be intelligent to know about each other so that a tag at the top of the page that generates the routines can know ahead of time what routines to generate based on the widgets that appear later in the page. It seems solvable but also a bit hard and scary. While it is possible to make JS-specific components (as a first cut)... I wouldn't want to lose site of the fact that the JS could be an add-on and maybe it is possible that it should be it's own abstract that the widget set needs to be able to hook into but isn't built into separate widgets. The red flag comes in seeing examples like Widget::HTML::DateDropDown Widget::HTML::UserAgentDate Widget::HTML::JSDate if it is like this, then you may have many date widgets flying aroudn that are all HTML widgets but share features with a lot of copy and paste between them which isn't very clean OO. As I write this I am quite sleepy and so please forgive my lack of constructive critique. I just want to point it out and maybe we can revisit this. We don't have to code the JS abstraction but if it is clearly outlined where stuff like JS should interact with the widget library and where it should not, then it will make the job of developing the widget library easier. >Sounds fun! I agree!
Re: Real Widgets and Template Languages
Hey all, Let me describe what I have been imagining as the ideal widget for what I am writing: 1 - it can look to its environment to determine how to render itsself - am I on an HTML page or something else? 2 - it has properties that can be set and remain static no matter who's using it - size, shape, colour, max, min 3 - it has properties that are customized by the individual user of the widget - current value, theme choice, 4 - it can tell developers and environments what it can do - switch_on, switch_off, increment, decrement, etc. 5 - it is capable of persisting from invocation to invocation - user 1 sets current_value to x - which always comes back for user 1 6 - it can look to its environment for interhitable properties - global theme choice, global font, etc. 7 - templating systems know how to call widgets - because they always use the same method to display themselves 8 - widget can interact with each other - increasing value on slider widget changes current record # value for database record widget 9 - access restrctions - users can override some values but not others - not everyone can even use this widget, etc. 10 - multilingual - some things are language neutral others are not - "size" would probably be neutral whereas "label" would be language sensitive 11 - above all it is easy to use - ie/ don't make me set a zillion properties just to make it work! I am going to throw out a buzzword, gasp, which may serve as a model for what we are talking about: JavaBeans. I do feel there is a lot of additional complexity there but it is along the right direction IMHO. If you translate my wishlist into technologies I think I am talking about: A - a good persistant object management environment B - user sessions C - integration of widgets (objects) to user sessions D - Object API (properties and methods) which are consistant and predictable E - self documenting objects This is what I have been looking for/writing myself! I am really eager to chip in on this project and get it going ASAP - but do acknowledge the need for hearty discussion about what people really want not just my own views. :)) Jay
Re: Real Widgets and Template Languages
darren chamberlain <[EMAIL PROTECTED]> writes:
> Chip Turner ([EMAIL PROTECTED]) said something to this effect on 05/23/2001:
> > If I could make a suggestion -- don't depend upon a CGI.pm interface
> > for form variables. Abstract it away. One option would be to use
> > closures:
>
> I agree with not relying upon CGI, but using closures still
> requires some knowledge of the object type. Something simpler
> would be to assume that an object passed in has a param method
> that behaves the way CGI.pm's and Apache::Request's param do.
> Something like:
Not true at all.
my $cgi = new CGI;
my $cgi_param = sub { return $cgi->param(shift) };
my $asp_param = sub { return $Request->{+shift} };
etc
The nice thing about closures is they could hide any interface at all
behind them; all that is required is that the function that generates
the closure follow the very simple convention of "return the formvar
of the name starting with the first parameter you're called with."
There is absolutely no reliance upon the underlying object structure.
What you're suggesting is equivalent to assuming the object is derived
from some kind of base class that supports the param() method though
without actually having to be ISA of that class. That's naughty OO
programming :) Just because perl lets you be typeless doesn't mean
it's always in the best interest of clean design to do so.
Closures are excellent in hiding implementation details of simple
operations, and I think in this case they fit quite well. The system
can even be written to work just fine without the user using closures
if they're using CGI.pm, as in my previous example.
Chip
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
Chip Turner ([EMAIL PROTECTED]) said something to this effect on 05/23/2001:
> If I could make a suggestion -- don't depend upon a CGI.pm interface
> for form variables. Abstract it away. One option would be to use
> closures:
I agree with not relying upon CGI, but using closures still
requires some knowledge of the object type. Something simpler
would be to assume that an object passed in has a param method
that behaves the way CGI.pm's and Apache::Request's param do.
Something like:
my $q = CGI->new;
# or:
# my $q = Apache::Request->new($r);
# and so on.
my $widget = Widget::Controller->new('factory' => $q);
(I made up the term 'factory'; I hope it's clear what I mean from
the context.)
# Widget::Controller:
sub new {
my $class = shift;
my %args = @_;
# stuff...
if (defined $args{'factory'} &&
UNIVERSAL::can($args{'factory'}, 'param'))
{
$self->{'factory'} = $args->{'factory'};
}
# more stuff
}
This way, anything with a params method can be used. I am unsure
about whether Apache::ASP has a param method, but perhaps one
could be added:
# Apache::ASP
sub param {
my $self = shift;
my $what = shift;
if (defined $Request->Form->{$what}) {
return $Request->Form->{$what};
} ## ^ what is this called?
# more stuff
}
Or whatever. You get the idea.
So, from within the Widget object or a subclass, you call:
my $val = $widget->factory->param('foo');
... and it doesn't matter what the factory is. This breaks down
with modules like HTML::Template which have a param method that
does completely different things, and (possibly) modules that
AUTOLOAD methods.
> That way the user can easily give you different sources of formvars
> (libapreq, Apache::ASP's hash, plus others not yet public) and yet you
> still get the flexibility you need.
It seems to me that, because CGI.pm has become the standard, and a
lot of people have experience programming CGI scripts with it, it
has become pretty standard for CGI-ish modules to have param
methods that behave like CGI.pm's does. This assumption is
underlying the above suggestion. Is that a good assumption?
Littering the code with tons of "if ref $_[0] eq 'ThisModule'"
seems ugly and hard to maintain, and has the potential to
introduce bugs and unintentional omissions too quickly.
> I would suggest using a class for this kind of thing, but
> realistically it's a bit much to expect users to derive classes just
> for something as simple as this. By supporting the coderef closure
> internally, you don't force users to understand what's going on, but
> still allow for more advanced users to use different interfaces. Plus
> you remove dependance on a web server.
I agree with you--it's the Right Thing To Do, but we aren't
writing Java here. Liberal use of UNIVERSAL::can should be all
that is needed to handle this situation.
A Widget::DefaultFactory (or whatever) class should be provided,
to be used by default, which has an empty param method.
As an aside, I like the approach the Template Toolkit takes for
using subclasses or replacements for internal functionality.
Defining your own module to be used internally (for example, a
new Provider, which is what reads the template file from disk or
a cache), you set $Template::Config::PROVIDER to the classname of
your replacement, and the other Template modules get the right
class by doing something like:
$Template::Config::PROVIDER = 'My::Groovy::Provider';
my $provider = Template::Config->provider(\%options);
And the right type of object gets returned (Template::Config
loads the module when it is called). My only complaint
about this is that the interface (assigning to a global) could be
cleaner.
Just some thoughts.
(darren)
--
The first human who hurled an insult instead of a stone was the founder of
civilization.
-- Sigmund Freud
Re: Real Widgets and Template Languages
> I will step up to write this code. (if it is what I think it is) > I have responded to the message by beginning a requirements document. > >http://www.officevision.com/pub/HTML-Widget/ > > Please read it and send me any comments. > The following are the questions I need advice on in order to proceed. > > * What CPAN package namespace should I use? > I studied the existing packages, and what we are trying to do looks > like it fits under the existing top level package HTML. > I propose to take the space "HTML::Widget" (see package layout in > design doc). Gunther suggested the top-level "Widget" name space. > I was under the impression that we should stay away from creating > new top-level entries at CPAN unless there was really *nothing* > similar. Confusingly, there is already an HTML::Widgets. Thoughts? First, I think it's not important to get started with. I think we can start with Widget:: given that the code is not strongly tied to HTML. In fact think of the email templates where you want the widget to do the right thing when a respond is sent via email and not HTML (not talking about certain companies who want the emails to be sent in HTML). Once we have more code written, we can talk to the CPAN gods (Andreas Koenig and alike) and particularly comp.languages.perl.modules news group which is supposed to deal with it. If the class is well abstracted I don't think there will be a resistance to start a new namespace. But I think that a pure intention is not good enough to convince people. A working code always makes things easier. If the choice of the namespace will be proven to be wrong we can easily s/Widget::/Rocket::/ and do the filename renaming. So it's a non-issue I think. > * What CPAN packages should I begin with and build upon? > CGI and Apache::Request were mentioned. I figure I will use these. > HTML::StickyWidgets was also mentioned. Do you mean HTML::StickyForms? > Are there others I should build dependencies on? I think we are talking about thing that should be very abstract, so you probably can use whatever you feel comfortable with, probably CGI.pm/Apache::Request on one side and CGI.pm/HTML::StickyForms on the other side to start with. But we have to make sure that other packages will be easily plugged in. This is something that we call 'drivers' in our extropia.com ADT, you need only to write a driver for a particular service/module to make use of this service/module, without changing your applications. Well you know that already from DBI:: world. Then later on someone will come up with a plugin for TT and other templating systems... > * Should I begin immediately with a new Sourceforge project? another way? > The codebase I will begin with is in CVS on my local server. > Perhaps I should just continue that way and post versions to CPAN > for distribution. However, we may have email traffic for the project > that exceeds the general interests of the modperl list. Thoughts? > I would need to get enough responses from people who would join that > Sourceforge mailing list before it would be worth it to go do that. sourceforge is a good idea as it gives you a public cvs and mailing lists. (bug tracking and etc). I don't think that things should be placed on CPAN yet. Once you have a working version, that's when it should get released on CPAN. Of course these are only my thoughts... :) As the leader of the project you decide how you want things to be done, and we can just try to push you into the _right_ direction :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Real Widgets and Template Languages
If I could make a suggestion -- don't depend upon a CGI.pm interface
for form variables. Abstract it away. One option would be to use
closures:
my $cgi = new CGI;
my $formvar = sub { $cgi->param(@_) };
my $wc = HTML::Widget::Controller->new(\%config, $formvar);
Or possibly, inside the constructor, do something like:
sub HTML::Widget::Controller::new {
my $class = shift;
my $config = shift;
my $cgi = shift;
if (ref $cgi and ref $cgi eq 'CGI') {
my $tmp = $cgi; # not strictly necessary, but it makes it clearer
$cgi = sub { $tmp->param(@_) };
}
...
}
That way the user can easily give you different sources of formvars
(libapreq, Apache::ASP's hash, plus others not yet public) and yet you
still get the flexibility you need.
I would suggest using a class for this kind of thing, but
realistically it's a bit much to expect users to derive classes just
for something as simple as this. By supporting the coderef closure
internally, you don't force users to understand what's going on, but
still allow for more advanced users to use different interfaces. Plus
you remove dependance on a web server.
Chip
Adi Fairbank <[EMAIL PROTECTED]> writes:
> Stephen,
>
> I read your proposal and I like it a lot. I will help filling out the
> HTML::Widget::HTML* space (in your package structure suggestion).
>
> However, I like Gunther's suggestion for a namespace of Widget:: better than
> HTML::Widget::, because it will not be exclusively HTML, but WML, JS10,
> etc. But either one is fine with me.
>
> Sounds fun!
> -Adi
>
> Stephen Adkins wrote:
> >
> > Hi,
> >
> > I will step up to write this code. (if it is what I think it is)
> > I have responded to the message by beginning a requirements document.
> >
> >http://www.officevision.com/pub/HTML-Widget/
> >
> > Please read it and send me any comments.
--
Chip Turner [EMAIL PROTECTED]
RHN Web Engineer
Re: Real Widgets and Template Languages
Stephen, I read your proposal and I like it a lot. I will help filling out the HTML::Widget::HTML* space (in your package structure suggestion). However, I like Gunther's suggestion for a namespace of Widget:: better than HTML::Widget::, because it will not be exclusively HTML, but WML, JS10, etc. But either one is fine with me. Sounds fun! -Adi Stephen Adkins wrote: > > Hi, > > I will step up to write this code. (if it is what I think it is) > I have responded to the message by beginning a requirements document. > >http://www.officevision.com/pub/HTML-Widget/ > > Please read it and send me any comments.
Re: Real Widgets and Template Languages
Hi, I will step up to write this code. (if it is what I think it is) I have responded to the message by beginning a requirements document. http://www.officevision.com/pub/HTML-Widget/ Please read it and send me any comments. The following are the questions I need advice on in order to proceed. * What CPAN package namespace should I use? I studied the existing packages, and what we are trying to do looks like it fits under the existing top level package HTML. I propose to take the space "HTML::Widget" (see package layout in design doc). Gunther suggested the top-level "Widget" name space. I was under the impression that we should stay away from creating new top-level entries at CPAN unless there was really *nothing* similar. Confusingly, there is already an HTML::Widgets. Thoughts? * What CPAN packages should I begin with and build upon? CGI and Apache::Request were mentioned. I figure I will use these. HTML::StickyWidgets was also mentioned. Do you mean HTML::StickyForms? Are there others I should build dependencies on? * Should I begin immediately with a new Sourceforge project? another way? The codebase I will begin with is in CVS on my local server. Perhaps I should just continue that way and post versions to CPAN for distribution. However, we may have email traffic for the project that exceeds the general interests of the modperl list. Thoughts? I would need to get enough responses from people who would join that Sourceforge mailing list before it would be worth it to go do that. Stephen >There has been some discussion on the list lately about generating widgets >ala CGI.pm, HTML::StickyWidgets etc... > >The thing is that these products or plug-ins are very HTML oriented. The >widget is defined as an HTML widget like a textfield or checkbox or >dropdown or what-have-you. > >What I am really looking for is a library that abstracts and allows widgets >to be developed that are tied to an application not to a set of HTML >necessarily. I guess I will start by providing an example of what I want >based on what we currently do in our Java framework when he use Templating >there. I'd like it if someone has developed the same thing in Perl that we >could reuse, otherwise, we may need to write this. <... snip ...>
Re: Real Widgets and Template Languages
On Wed, 23 May 2001, Gunther Birznieks wrote: > Hmmm. I had not thought of this because we do not provide this capability > now in the Java widget library that we have and we don't really miss it. > > For color, most UI widgets do not have color. For font and height, I think > that most designers don't change this often and if they do, it can be > adjusted in the config file ... usually the widgets themselves don't change > -- it's the stuff around the forms that do 90% of the time. I guess what I am really thinking about is things like JavaScript Events. The widget would be able to automatically add an onChange JS function to do client side validation of data. But a designer might want to add an onMouseOver to a widget that will display a layer with a hint describing how that field should be filled in. You could just add support for MouseOver Hints to the widget library, but I could probably come up with a bunch of other things a designer might want to change on a widget to get it to do, and look how they want. Cees
Re: Real Widgets and Template Languages
At 08:54 PM 5/23/2001 +1000, Cees Hek wrote: >On Tue, 22 May 2001, Gunther Birznieks wrote: > > >This sounds very useful and powerful. I've been looking for a project to >help out with, and this one sounds interesting to me. Let me know if you >want some help developing it, or someone to bounce ideas off... Yes! > > > >First Name: > >Last Name: > >Comments > > > >One thing that I think is very important is to let designers have control >over the look and feel of the interface. Your widget library should have >some mechanism to allow a template designer to specify attributes for a >widget (like width, height, colour, etc...). > > >- or - > > >You can still allow programmers to have control over how the data is >verified, and other attributed like maxlength for text fields and >such. > >Of course these attributes will not be useful in every type of widget. >ie if the programmer decided that this widget is going to be a text field >instead of a textarea, then the above height attribute would be useless, >and ignored. Hmmm. I had not thought of this because we do not provide this capability now in the Java widget library that we have and we don't really miss it. For color, most UI widgets do not have color. For font and height, I think that most designers don't change this often and if they do, it can be adjusted in the config file ... usually the widgets themselves don't change -- it's the stuff around the forms that do 90% of the time. However, it does bring up an interesting point. On the one hand, I want to abstract away from the designer what the widget is. For example, it should be up to the app developer whether I use a textfield or a text area. But defining a "width" for a text area is very different from defining a width for a text field. I realize that in the ideal world we would separate these concerns out. But having tried it the HTML::StickyWidgets way and the application widget way, I know that I like the application widget way better. I think there is room for your idea though but I haven't honestly thought about it.
Re: Real Widgets and Template Languages
At 02:26 PM 5/22/2001 -0400, kyle dawkins wrote: >On Tue, 22 May 2001 06:25, Matt Sergeant wrote: > > On Tue, 22 May 2001, Gunther Birznieks wrote: > > > I want/need a *Perl* solution! > > > > Well if you can pay for it... (still unemployed here and getting poorer > > waiting for people to possibly say yay or nay on possible contracts...) > >Ummm... you guys could look at > >http://www.smartworker.org Ummm... you could also read my first post on the subject which already mentioned smartworker. Smartworker isn't what we need to accomplish what I am talking about. Smartworker has a great UI framework but it is a UI framework. It does not operate at the level of application logic which is the level I wish to have widgets operate under. I realize this is a difficult concept to both explain and understand. Hopefully the rest of my post will put it in a different nutshell. >And if that's not your cup of tea, I should be releasing something sometime >in the fairly near future that will be. I am not sure. It would be great if that was the case! Could you describe in a few sentences what you will be releasing? I don't think you precisely understood what I was asking for or read my entire post if you just forwarded me to smartworker again, so I hope you forgive my skepticism. As mentioned, if what you can provide does what I want, then that would be great. What I don't want: Another HTML Widget library or another UI library What I do want: A way of logically specifying an application-based widget (eg post something saying that is intelligent enough to know how to render itself based on an application config.
Re: Real Widgets and Template Languages
On Tue, 22 May 2001, Gunther Birznieks wrote: > What I am really looking for is a library that abstracts and allows widgets > to be developed that are tied to an application not to a set of HTML > necessarily. I guess I will start by providing an example of what I want > based on what we currently do in our Java framework when he use Templating > there. I'd like it if someone has developed the same thing in Perl that we > could reuse, otherwise, we may need to write this. This sounds very useful and powerful. I've been looking for a project to help out with, and this one sounds interesting to me. Let me know if you want some help developing it, or someone to bounce ideas off... > >First Name: >Last Name: >Comments > One thing that I think is very important is to let designers have control over the look and feel of the interface. Your widget library should have some mechanism to allow a template designer to specify attributes for a widget (like width, height, colour, etc...). - or - You can still allow programmers to have control over how the data is verified, and other attributed like maxlength for text fields and such. Of course these attributes will not be useful in every type of widget. ie if the programmer decided that this widget is going to be a text field instead of a textarea, then the above height attribute would be useless, and ignored. Cees
Re: Real Widgets and Template Languages
Hey all, I have been giving this very subject area a lot of thought myself - I would like to really make a push for HTML/interface widgets in Perl. Have done some work to that end and have a lot of ideas. In addition I was thinking about making an investment of time and resources into this idea to bring it to something useful and exciting for developers. Was just starting to solicit opinions from developers myself. Would be glad to chip in to a common effort here! Jay On Tue, 22 May 2001, Adi Fairbank wrote: > > Gunther, > > I have been interested in the concept of an HTML widget module for a while > now. The reason being, my application currently generates all HTML using > CGI.pm in a mod_perl handler OO-style design, and we are starting to notice > patterns.. similar pieces of HTML that get generated over and over. > Needless to say, componentized, reusable widgets would be very useful for > us. > > Though I can't make the commitment of writing it myself (if I did, it would > be about 6 months before you saw any code), I would definitely contribute to > it, if it existed. And like you said, the hard part is getting people to > write the widget objects. > > -Adi
Re: Real Widgets and Template Languages
Gunther, I have been interested in the concept of an HTML widget module for a while now. The reason being, my application currently generates all HTML using CGI.pm in a mod_perl handler OO-style design, and we are starting to notice patterns.. similar pieces of HTML that get generated over and over. Needless to say, componentized, reusable widgets would be very useful for us. Though I can't make the commitment of writing it myself (if I did, it would be about 6 months before you saw any code), I would definitely contribute to it, if it existed. And like you said, the hard part is getting people to write the widget objects. -Adi
Re: Real Widgets and Template Languages
On Tue, 22 May 2001, Gunther Birznieks wrote: > > > Has someone done this already? > > > >Struts. But you knew that already :-) > > For those that do not know struts is a Java framework and I think someone > is trying to get me riled up! > > I want/need a *Perl* solution! Well if you can pay for it... (still unemployed here and getting poorer waiting for people to possibly say yay or nay on possible contracts...) -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Real Widgets and Template Languages
At 10:13 AM 5/22/2001 +0100, Matt Sergeant wrote: >On Tue, 22 May 2001, Gunther Birznieks wrote: > > > Does anyone have a widget framework like this? I think the closest I found > > to widget abstraction is SmartWorker, but it is not abstract in quite the > > way that I want above. > >We're planning to do something like this as a taglib in XSP for AxKit. >It's quite a big task though, as we want widgets to also be intelligent in >the way they are mapped to forms processing code. I think it is a big task. On the other hand, in thinking about it, I think the actual logic behind widgets could be fairly simple. The hard part is getting people to write the various widget objects. Again, I think all the various HTML widgets could use an underlying library like HTML::StickyWidgets. And then the remaining hard part is writing the template language wrappers that actually allow them to be embedded in pages as tags where it is XSP tags for AxKit or plugins for TemplateToolkit. > > Has someone done this already? > >Struts. But you knew that already :-) For those that do not know struts is a Java framework and I think someone is trying to get me riled up! I want/need a *Perl* solution! :)
Re: Real Widgets and Template Languages
On Tue, 22 May 2001, Gunther Birznieks wrote: > Does anyone have a widget framework like this? I think the closest I found > to widget abstraction is SmartWorker, but it is not abstract in quite the > way that I want above. We're planning to do something like this as a taglib in XSP for AxKit. It's quite a big task though, as we want widgets to also be intelligent in the way they are mapped to forms processing code. > Has someone done this already? Struts. But you knew that already :-) -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Real Widgets and Template Languages
There has been some discussion on the list lately about generating widgets
ala CGI.pm, HTML::StickyWidgets etc...
The thing is that these products or plug-ins are very HTML oriented. The
widget is defined as an HTML widget like a textfield or checkbox or
dropdown or what-have-you.
What I am really looking for is a library that abstracts and allows widgets
to be developed that are tied to an application not to a set of HTML
necessarily. I guess I will start by providing an example of what I want
based on what we currently do in our Java framework when he use Templating
there. I'd like it if someone has developed the same thing in Perl that we
could reuse, otherwise, we may need to write this.
A widget should be a plugin or tag that may be embedded in a template with
the definition of that widget tied to some APPLICATION-LEVEL piece of data
entry not at the HTML-LEVEL.
For example,
First Name:
Last Name:
Comments
As you can see the basic idea is that the tag (or it could be Perl
object embedded in the template) is actually *intelligent*.
It should be configured as a Perl object that knows that an fname is a
textfield and an lname is a textfield and a comments field is a text area.
And if I change my mind and decide that comments is better off as a
textfield, I should not have to change any templates that use the tag.
Now, HTML::StickyWidgets and CGI.pm could be used by a true widget
abstraction library to generate HTML widgets. But what I want to do is
provide the capability of also abstracting even higher. Like at the data level.
I forsee a
WidgetCollection class which holds widgets together
Widget class that provides the interface to what a widget does
and Widget:: subclasses that provide definitions relevant to the widget
types used on the forms.
Where HTML::StickyForms comes in is something like
Widget::HTML::TextField
Widget::HTML::TextArea
Widget::HTML::CheckBox
etc...
This is extensible as we provide more cross platforms ones can be added as
Widget::WML::TextField
Widget::WML::CheckBox
And it support intelligence...
Widget::HTML::Date is a widget that would actually contain a drop down for
month, a drop down for day and a drop down for year parts of a Date.
But the widget object itself can set and get it's data as a Date string.
In other words, the nice thing about a generic Widget library is that you
can start easy (aka HTML::StickyWidgets) but you can end up with a library
of common tags that many applications require.
I believe such a library of widget plug-ins could be made semi-indepenent
of the templating language used with perhaps plugin wrappers for each one
(In particular I am interested in TemplateToolkit).
The way these widgets would be configured is something like the following
my $widget_collection = new WidgetCollection(
-WIDGET_FORM_DATA => $CGI , # (CGI.pm object)
-WIDGET_HASH =>
'fname' => new Widget(-TYPE => HTML::TextField, -NAME=> "fname")
'lname' => new Widget(-TYPE => HTML::TextField, -NAME=> 'lname'),
'birthday' => new Widget(-TYPE => HTML::Date, -DAY_NAME => "dob_day")
)
Then if I want to get a widget...I can say
my $widget = $widget_collection->getWidget('fname');
By default the widget object data is set using the CGI.pm object (or
Apache::Request)
But you can manually get and set the data...
print $widget->get_value();
or
$widget->set_value("gunther");
In the case of a date widget... you can do something like
$widget->set_value("5/22/2001"); if the format defined in the constructor
of the date widget was "5/22/2001" for mm/dd/
And most importantly, widgets know how to display themselves...
print $fname_widget->display(); prints the HTML text field
whereas
print $date_of_birth_widget->display(); prints the three drop downs that
represents the month day and year.
Of course, the widget library could be expanded by the open source
community. For example, I can imagine a date widget that also has a button
that says "Click for Calendar"... and then a javascript popup comes up with
a mini-calendar for selecting the date.
Does anyone have a widget framework like this? I think the closest I found
to widget abstraction is SmartWorker, but it is not abstract in quite the
way that I want above.
What I want is a business or application context widget that can be
configured on-the-fly to be something other than a plain HTML widget. After
using this concept in our Java toolkit for 6 months, I find the abstraction
to be quite useful and really want to have the same feature in Perl.
Has someone done this already?
Thanks,
Gunther
