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
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
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
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
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 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
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
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
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;
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
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
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
::
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
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
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
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
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
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
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:
Widget type=textbox maxsize=50 length=25
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
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
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
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
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
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
]; 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
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
Gunther Birznieks wrote:
snip/
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
[[ 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
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
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
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
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
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
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,
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
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
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.
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
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...
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
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
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
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
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
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
76 matches
Mail list logo
