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.