[PEAK] Towards a GUI facility for PEAK

Niki Spahiev niki at vintech.bg
Thu Dec 23 12:33:47 EST 2004


Phillip J. Eby wrote:
>>> Nice.  There actually is some minor coupling from my POV, in that 
>>> Action and InitAll receive 'view' and perform actions on it.  In the 
>>> ideal situation, InitAll would be replaced by e.g an events.Value 
>>> subscribed to by the GUI.
>>
>>
>> As i said this design is 10 years old. Now its time to refactor it using
>> PEAK.
>>
>> I experimented with view as Observer and showing same model in many
>> windows is something that we use in our latest releases. This way
>> InitAll stays but is called from view only, no internal calls to
>> InitAll are allowed. Maybe an events.Value should hold the object (m) and
>> all views should call m.InitAll(self)?
> 
> 
> What I'm saying is that instead of having mapping items in the view like 
> 'data' and so forth, those items would be exposed as values on the 
> model, and subscribed-to by the view.  In order for the mapping to be of 
> any use, obviously the view has to know what they correspond to, so it's 
> just as easy for the view to pull them off the model and subscribe to 
> any of them that are needed.  Using your current design, you could 
> literally just subscribe a function that calls the view's __setitem__ in 
> order to keep the current implementation.  Thus, there's never a need 
> for an InitAll().  Does that make sense?

Yes, but looks too fine grained to me. For example pyro can be used 
between view and presenter (for no better term). Sending value by value 
over net is not good for performance. Also Web forms use batches forward 
and back. Our first version was value by value, but we found that this 
is not necessary.

>>>  And I'd tie the buttons to methods rather than using the 100+digit 
>>> ID values, since if I understand correctly, those IDs have to be 
>>> chosen to suit the GUI layer.
>>
>>
>> In test_calc.py number IDs for buttons 0-9 are because i am lazy. They
>> are not necessary and can all be replaced by event names as is done for
>> 'add' and 'sub'. IMO routing from events to actions is task that not
>> always involves method call as first step e.g. Taskmaster pattern sends
>> all events to state machine which then generates some method calls.
> 
> 
> Sure, but either the state machine is pure UI, or else it's part of the 
> model.  If it's in the UI, sure, let the view manage the state machine 
> and call the model when a model-level action is required.  If the state 
> machine is part of the model, then do that.  The point is just that the 
> model has no business interpreting UI events; it should just ultimately 
> receive model method calls.  Thus, there's no need for an Action() method.

In my code view is dumb web form like medium for displaying things and 
receiving input from user. All intelligence is in middle translating 
layer - CalcXXX in test_calc.py. Signal / slot like wiring is done in it 
in order to allow using and changing many standard view-form 
implementations.

>>> Indeed, I'd do away with 'Action' and 'InitAll' altogether, because 
>>> they're both artifacts of the GUI.  But apart from that, yes, this is 
>>> very similar to the concept I proposed here.
>>
>>
>> Main use of Action( view, .. ) is to call view.AttachFrame(..) to open 
>> new windows.
> 
> 
> I think this could be handled by some sort of "ui.show(anotherModel)" 
> operation, perhaps with some options.  But, it's actually more likely 
> that this will be handled by views on command objects, because otherwise 
> it would be difficult to handle "modal" windows in a web UI.  That is, 
> there can't be a function called by the model to get input, because the 
> model should receive input in the form of command instances populated 
> with parameters.  The UI framework should handle finding and presenting 
> a view for the command object, and then executing the command once the 
> input has been obtained.

GUIs usually need more parent/child information in order to work as 
expected.


>>  Not sure about InitAll, its responsible for reconfiguring UI too.
> 
> 
> How do you mean?

In test_calc2 InitAll enables/disables some view elements according to 
current state. This can be observed too, but configuration space is too 
big for effectively doing that.

>> Here is better example (still not using subscription). What is the 
>> English name of concept represented by CalcXXX?
> 
> 
> I don't know; I wouldn't split the two up like that.  I'd make the 'oct' 
> flag an events.Value on the model, and subscribe to it from the view.  
> I'd probably also make a 'display' attribute (also an events.Value) on 
> the model that was the string to be displayed (decimal or octal).  The 
> action mappings (digit->digit(), add/sub/etc.) I would put on the view, 
> as calling methods or issuing Commands of some kind.  (Where the 
> Commands call the model methods.)

oct has nothing to do with model. Model always uses ints. Displaying and 
entering digits is pure UI task IMO. Presenter is not good name, 
especially as its taken for similar UI concept

http://www.object-arts.com/EducationCentre/Patterns/MVP.htm

>> P.S. I would like this design to be compatible with Web.
> 
> 
> The tricky part of doing this with the calculator would be keeping track 
> of the state (a,b,sign,oct).  Sessions are a classic way of handling 
> this, but for some web applications it would be preferable to put this 
> information directly into a cookie, or into the URL or form data.  This 
> suggests that models may need to be able to provide a (possibly 
> structured) memento of their current state.

Yes i know that. IMO state keeping is orthogonal concept and sometimes 
single user apps are handy too.

Niki Spahiev



More information about the PEAK mailing list