perl-widget-developer Mailing List for Perl Widget Library (Page 11)
Status: Alpha
Brought to you by:
spadkins
Menu
▾
▴
perl-widget-developer — Discussion about bugs and further development of Perl Widgets
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(132) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
(6) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(9) |
| 2007 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(19) |
Sep
(6) |
Oct
(5) |
Nov
(5) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(7) |
Mar
(34) |
Apr
(13) |
May
(15) |
Jun
(5) |
Jul
(14) |
Aug
(6) |
Sep
(6) |
Oct
(3) |
Nov
(1) |
Dec
|
|
From: Stephen A. <ste...@of...> - 2001-06-01 02:29:11
|
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. <Please do *not* discuss this post on the modperl list, only on perl-widget-developer.> 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 <head> 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 |
|
From: Gunther B. <gu...@ex...> - 2001-06-01 01:05:55
|
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:
> > >
> > ><Widget type="textbox" maxsize="50" length="25" X-Offset="40"
>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:
> > ><INPUT TYPE="TEXT" MAXLENGTH="50" SIZE="25" NAME="text1" VALUE="some
>sample
> > >text" onMouseOver="Window.status='Enter some text here'"
> > >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:
> > >
> > ><Widget type="textbox" maxsize="50" length="25" name="text1" value="some
> > >sample text" tooltip="Enter some text here"/>
> > >
> > >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.
|
|
From: Issac G. <ne...@wr...> - 2001-06-01 00:51:21
|
> 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" X-Offset="40"
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:
> ><INPUT TYPE="TEXT" MAXLENGTH="50" SIZE="25" NAME="text1" VALUE="some
sample
> >text" onMouseOver="Window.status='Enter some text here'"
> >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:
> >
> ><Widget type="textbox" maxsize="50" length="25" name="text1" value="some
> >sample text" tooltip="Enter some text here"/>
> >
> >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.
|
|
From: Issac G. <ne...@wr...> - 2001-05-31 22:04:57
|
testing my post privs... 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 |
|
From: Stephen A. <ste...@of...> - 2001-05-31 20:52:19
|
Hi,
Let's start small, shall we?
Everybody knows that Coding Standards are a pain, but they're
necessary. Here are two.
* Use 4-space indentations (like Java coding standards from Sun)
* No tabs!
Procedural note:
* If you need to reformat code, try to do it on a separate
CVS commit from any functional changes you may have made.
Stephen
|
|
From: Stephen A. <ste...@of...> - 2001-05-31 20:34:50
|
Hi,
We welcome James Smith to the team of developers for the Perl Widget Library.
James, here is the philosophy.
I gave you Developer privileges and a couple other privileges because
1. I am new to the Sourceforge system and I don't really know the
implications
of granting or denying a particular privilege. If you find you have
not enough privileges or too many or more or less than some other
developer,
it is probably because I don't know what I'm doing rather than that I
conspired
against you. Just let me know and I'll remedy that.
2. I wish to err on the side of openness. I believe that "Developer"
privilege comes
with CVS commit capability. A more prudent approach might be to let
users have
anonymous CVS access at first and encourage them to submit "cvs diff"
patches.
However, the project is so small now, I want to encourage new
developers to get
involved. I ask you to use your good judgment. Check out the code.
Make changes.
Implement features. But please discuss them on the list before "cvs
commit"-ing
them. The project is young. My strategy of "openness" (glasnost?)
could cause
the project to fall apart if too many developers try to pull it in
their own
direction without cooperating.
Thanks,
Stephen
At 01:06 PM 5/31/2001 -0700, James Smith wrote:
>Thought I'd see if you wanted my help on developing the
>widget code. I've been following the discussion on the
>mod_perl list.
>
>I updated my profile (username jgsmith) with an informal
>resume and skills list.
>--jim
>
|
|
From: Issac G. <ne...@wr...> - 2001-05-31 18:44:17
|
----- Original Message -----
From: "Issac Goldstand" <is...@ma...>
To: "Gunther Birznieks" <gu...@ex...>; "Stephen Adkins"
<ste...@of...>
Cc: <per...@li...>; <mo...@ap...>
Sent: Thursday, May 31, 2001 21:14
Subject: 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 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.
>
> 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.
>
> 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:
>
> <Widget type="textbox" maxsize="50" length="25" X-Offset="40"
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:
> <INPUT TYPE="TEXT" MAXLENGTH="50" SIZE="25" NAME="text1" VALUE="some
sample
> text" onMouseOver="Window.status='Enter some text here'"
> 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:
>
> <Widget type="textbox" maxsize="50" length="25" name="text1" value="some
> sample text" tooltip="Enter some text here"/>
>
> 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).
>
> > >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
> > >(<select>),
> > >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.
> >
> > Yes. A widget should be *physical*. And it is possible for controllers
to
> > be logical and understand how to call upon WAP widgets and HTML widgets
> > when the time comes. Or it can be as simple as I mentioned before where
> you
> > just define different containers -- a WAP container and an HTML
container.
> > And then that's it. It's up to the applicaiton to choose to use the WAP
vs
> > HTML container, not the container itself to understand what browser it
is
> > running under.
>
> I think the idea here is similar (if not the same as) my "default control"
> idea, in that if a Widget is requested in environment that doesn't
actually
> support it, the design could be "engineered" in a different manner
producing
> a similar result (similar to hardware vs software 3D graphics rendering -
> we're essentially creating a HAL for our widgets) - or if that's
impossible,
> it would report it either to the programmer, the end-user or both.
>
> 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
>
>
|
|
From: Stephen A. <ste...@of...> - 2001-05-31 17:36:52
|
Hi, What are your initial thoughts from taking the first look at the code? Stephen |
|
From: Jay L. <Ja...@La...> - 2001-05-31 13:49:03
|
|
From: Stephen A. <ste...@of...> - 2001-05-30 17:51:29
|
Testing ... |
|
From: Stephen A. <ste...@of...> - 2001-05-30 17:50:45
|
Testing... |
56 messages has been excluded from this view by a project administrator.
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X