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 pr
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:
> > > > >...
>
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 bloatin
> 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" TabIn
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 w
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 bec
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 HT
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 I1
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 s
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
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
:
> 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 ha
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 d
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 {
> >
>
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 r
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
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
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
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, w
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 o
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-develop
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 supp
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/Netscap
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
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 prop
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, wh
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 fr
[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->langua
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
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 us
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
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 displ
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
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,
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
> 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 GU
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
-
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
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,
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
> 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 sp
>
>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, t
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 class
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 wande
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
>> > f
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
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
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 h
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
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
>
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 t
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 actua
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 eve
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 ce
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 wi
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 checkin
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 a
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
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 q
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 implement
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
[[ 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
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 fo
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 conv
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 wit
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::, bec
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
u
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
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
> 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
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 constru
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,
e
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 procee
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 design
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
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 possibl
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 curr
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
id
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 o
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
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 planni
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.
I
82 matches
Mail list logo