perl-widget-developer

[Perl-widget-developer] VOTE: display() name

[Stephen A. <ste...@of...>]

Hi,

ISSUE #1:

I am requesting a quick vote to put to bed this naming issue.
I agree that we need a 

   $widget->display()

method.
My ordered votes for what to call it are:

   1. display()
   2. render()
   3. show()
   4. draw()

ISSUE #2 (related):

On HTML widgets, I think there is still a place for an html()
method.  This method has no parallels in the Gtk or Curses
widgets.  However, the difference is that calling the html()
method on an HTML widget simply requests the widget to report
the HTML that would be used.  Calling the display() method
(or render() or whatever) is a tacit promise that the HTML
will be displayed.

This information will be of use in handling the state management.
Variables in the State which have not been "display()ed" can
be maintained by creating <input type=hidden> elements.

It is because of this difference between the html() method
and the display() method that "display()" seems better to me
than "render()".

Please vote... or *forever* hold your peace.

Stephen

Re: [Perl-widget-developer] VOTE: display() name

[Issac G. <ne...@wr...>]

> ISSUE #1:
>
>
>    1. display()
>    2. render()
>    3. show()
>    4. draw()

1.  display()

> ISSUE #2 (related):
>
> On HTML widgets, I think there is still a place for an html()
> method.  This method has no parallels in the Gtk or Curses
> widgets.  However, the difference is that calling the html()
> method on an HTML widget simply requests the widget to report
> the HTML that would be used.  Calling the display() method
> (or render() or whatever) is a tacit promise that the HTML
> will be displayed.
>
> This information will be of use in handling the state management.
> Variables in the State which have not been "display()ed" can
> be maintained by creating <input type=hidden> elements.
>
> It is because of this difference between the html() method
> and the display() method that "display()" seems better to me
> than "render()".
>
Against. I still think a display "driver" should be loaded by the Controller
and used to display() any Widgets requested.  That seems to me the most
compatible with any type of Widget that we'll ever want to create, and
therefore means less overhead to expand the library later.

  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: [Perl-widget-developer] VOTE: display() name

[Gunther B. <gu...@ex...>]

At 01:56 PM 6/8/2001 -0400, Stephen Adkins wrote:
>Hi,
>
>ISSUE #1:
>
>I am requesting a quick vote to put to bed this naming issue.
>I agree that we need a
>
>    $widget->display()
>
>method.
>My ordered votes for what to call it are:
>
>    1. display()
>    2. render()
>    3. show()
>    4. draw()
>
>ISSUE #2 (related):
>
>On HTML widgets, I think there is still a place for an html()
>method.  This method has no parallels in the Gtk or Curses
>widgets.  However, the difference is that calling the html()
>method on an HTML widget simply requests the widget to report
>the HTML that would be used.  Calling the display() method
>(or render() or whatever) is a tacit promise that the HTML
>will be displayed.
>
>This information will be of use in handling the state management.
>Variables in the State which have not been "display()ed" can
>be maintained by creating <input type=hidden> elements.
>
>It is because of this difference between the html() method
>and the display() method that "display()" seems better to me
>than "render()".
>
>Please vote... or *forever* hold your peace.
>
>Stephen

I can't really vote on this because I definitely disagree with the reason 
you are putting forth for advocating the display() method.

Also it really skews the vote to throw out a whole new idea of why it 
should be called display and then ask people to vote on what it should be 
called without asking first for comments so that all the pros and cons can 
be listed more objectively. In addition, psychologically just putting 
display as the first choice will entice people to choose display().

:)

The reason I disagree is that I do not believe that widgets should know 
about generating hidden vars vs the rendered value. It's the same arguement 
for widgets not knowing how to generate readonly vs editable widgets that I 
brought up earlier.

It's fairly clear in my mind that widgets should render themselves and that 
they should only have one render() method. None of this 
display_hidden_state() display_editable() display_readonly type of methods. 
That's way too much for the widget API, IMHO.

I do think that displaying hidden state values is useful. However, I think 
it should be part of an API that allows a widget to generate values based 
on the values of other widgets. And I believe that state maintenance is so 
application specific, that there should be a widget devoted to 
demonstrating this.

In our Java widget API, we call the state the user is in the "User Gesture" 
and hence all actions and views get access to the user gesture object which 
also coincidentally knows what parameters are vital to keep around in order 
to maintain state. I think it would be appropriate for an HTMLContainer of 
widgets to know how to generate a state maintenance widget based on a config.

Gesture is a pattern that I believe the Java J2EE whitepapers endorse as 
the mechanism for passing data in a model-view-controller architecture.

[Perl-widget-developer] Guesture Pattern was VOTE: display() name

[Stephen A. <ste...@of...>]

At 11:30 AM 6/11/2001 +0800, Gunther Birznieks wrote:
>At 01:56 PM 6/8/2001 -0400, Stephen Adkins wrote:
...
>In our Java widget API, we call the state the user is in the "User Gesture" 
>and hence all actions and views get access to the user gesture object which 
>also coincidentally knows what parameters are vital to keep around in order 
>to maintain state. I think it would be appropriate for an HTMLContainer of 
>widgets to know how to generate a state maintenance widget based on a config.
>
>Gesture is a pattern that I believe the Java J2EE whitepapers endorse as 
>the mechanism for passing data in a model-view-controller architecture.

Gunther,

Can you point us to some online documentation about the Gesture pattern?

Stephen

Re: [Perl-widget-developer] Guesture Pattern was VOTE: display() name

[Gunther B. <gu...@ex...>]

1) I am wondering if [Perl-widget-developer] can be shortened to [pwdev] in 
these messages.

2) Here are the URLs:

http://java.sun.com/j2ee/blueprints/design_patterns/model_view_controller/index.html

The whole blueprint chapter is

http://java.sun.com/j2ee/blueprints/introduction/application_scenarios/index.html#1043774

The entire J2EE blue print is

http://java.sun.com/j2ee/blueprints/apmTOC.html


At 12:16 AM 6/11/2001 -0400, Stephen Adkins wrote:
>At 11:30 AM 6/11/2001 +0800, Gunther Birznieks wrote:
> >At 01:56 PM 6/8/2001 -0400, Stephen Adkins wrote:
>...
> >In our Java widget API, we call the state the user is in the "User Gesture"
> >and hence all actions and views get access to the user gesture object which
> >also coincidentally knows what parameters are vital to keep around in order
> >to maintain state. I think it would be appropriate for an HTMLContainer of
> >widgets to know how to generate a state maintenance widget based on a 
> config.
> >
> >Gesture is a pattern that I believe the Java J2EE whitepapers endorse as
> >the mechanism for passing data in a model-view-controller architecture.
>
>Gunther,
>
>Can you point us to some online documentation about the Gesture pattern?
>
>Stephen
>
>
>_______________________________________________
>Perl-widget-developer mailing list
>Per...@li...
>http://lists.sourceforge.net/lists/listinfo/perl-widget-developer

__________________________________________________
Gunther Birznieks (gun...@eX...)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/

[PW-dev] [Perl-widget-developer] List settings changes

[Jay L. <Ja...@La...>]

> 1) I am wondering if [Perl-widget-developer] can be shortened to [pwdev]
in
> these messages.

SUBJECT TAG CHANGE
I have made a change in the subject tag based on Gunther's good suggestion.
It will
now read as [PW-dev].

REPLY-TO ADDRESS CHANGE
In addition - I have changed the reply-to to be the list rather than the
author. I am sure we can agree that most correspondance should go to the
list by default. I personally don't want to see duplicate emails all the
time either.

If you don't like these changes please flame me directly and not on the
list. :)

Jay