Wednesday, August 24, 2005
Interactor
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter"
Date: Sat, 9 Feb 2002 14:27:48 -0000
Local: Sat, Feb 9 2002 10:27 pm
Subject: Re: Model View Presenter
Interactor is a specialised Handler and as such is usually held in the Presenter. The main difference between a Handler and an Interactor is that an Interactor usually copes with a timeline and is usually some kind of state machine.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Thu, 27 Nov 2003 10:01:46 -0000
Local: Thurs, Nov 27 2003 6:01 pm
Subject: Re: Feedback from a Selection
As you may have gathered, I use Interactors to respond to user gestures and these are responsible for telling the Selection to change.
Because an Interactor can be a State Machine, you can detect whether the Ctrl and/or Shift keys are pressed and Clear/Add/Replace the Selection accordingly from an appropriate State class of the Interactor.
Once the Selection has changed, the Model should then notify any Observers.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Mon, 24 Nov 2003 09:35:34 -0000
Local: Mon, Nov 24 2003 5:35 pm
Subject: Re: Linkage between Interactor, Commands and the Selection
Buttons on a form can be used in at least two different contexts:
1. They can be used to invoke Commands on the Model that is being presented in the form and, in that case, should be hooked up directly to Commands.
2. They can be used to spawn other Presenters that will display other aspects of the Model e.g. you are displaying a Customer and you want to display a list of all their Orders; The Order List is not a property of the Customer, but displaying the list is a facet of presenting a Customer.
I would hook such buttons up to simple event handlers within the Presenter for the object being displayed in the form.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Mon, 24 Jan 2005 17:12:15 -0000
Local: Tues, Jan 25 2005 1:12 am
Subject: Re: Validate data between Model and Controller in MVC
The real difference between MVC and MVP is that the 'message flow' is handled via two different 'channels', one for each direction.
The user makes a Gesture in the View
An Interactor responds to that Gesture (that Interactor may delegate reponsibility to nested Interactors, dependent on the complexity of the Gesture).
If that Gesture is intended to alter the visual selection in the View, the Interactor notifies the Selection in the Model.
Changes to the Selection are observed but he View and it is updated to match.
The Selection then notifies any Observers, one of which will be the View which will update itself accordingly, the other is the Command Set.
The Command Set updates itself based on the Selection to accomodate things like Commands not being available when more than one/only one item are/is selected.
Assuming that the Selection is now up to date, the Interactor translates subsequent Gestures, determines which Command on the Model is to be called and calls this Command.
Commands can be undone and redone and can alos support the concept of a history if required.
If executing the Command raises an exception, then the Interactor is responsible for creating a Presenter for that exception and directing the UI to a suitable focus point.
Assuming the Command succeeds, the Model, which contains the Value Type is passes the change to the Value Type.
The Value Type responds to the change by notifying any Observers, one of which would be the View.
This structure is more flexible in that Interactors and Commands can be relatively freely substituted depending on the nature of either the View or the Model.
MVPs can also be nested, so you get a MVP 'component' for a BO, the View of which will be a form, but this component will contain other MVP components, one for each of the properties of the BO, the views of which will be the edits on the form.
The inner MVP components can be created at runtime based on the names of the BO properties matching the 'PropertyName' of the relevant edit on the form.
I tend to talk about creating Presenters for Value Types; this then means that your client code usually creates/retrieves a Value Type (a BO is a composite Value Type) and then simply passes that Value Type to the constructor of a Presenter. The Presenter is responsible for creating a form or other display and will self-destruct when the form closes.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Tue, 23 Nov 2004 10:31:41 -0000
Subject: Re: Correct design ?
If you look at the articles on MVP, you will see that any forms that you create should have absolutely no code on them. Any events generated by buton or mouse clicks are handled in Interactors; thus allowing you to redisgn or replace forms without having to rewrite handler code.
It is the job of the Presenter to create an instance of an appropriate form and show it. The above code assumes that all Presenters create forms that are shown modally; you could not call Free for non-modal use, you would have an event handler in the business layer that would free off such a Presenter when the form closed.
As well as creating a form, the Presenter also populates the form from the object and hooks up the event handlers of the form to Interactor objects that respond by talking to the business object to update its state.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Thu, 2 Jun 2005 09:13:32 +0100
Local: Thurs, Jun 2 2005 4:13 pm
Subject: Re: How Interactor spawn others?
From my research, it should not be necessary to have a top level Interactor for the form if it is just to handle Buttons. Each of the buttons on a form should be wired up directly to a Command in the Model for the object being displayed on the form. In my MVP framework, Buttons implement the ICommandGuiObject, as do Menu items. Due to the simplicity of anticipated interaction between the Button and its related command, there really is no need for the complexity of an Interactor. Any Button or MenuItem should use the Observer pattern to detect when a Command is enabled/disabled; other than that, there is only the need to hold a reference to a Command in the Button and override the Click method of the Button or MenuItem to call the Execute method of the Command.
But when it comes to handling of Edits, Lists, etc; this relies on the Interactors that are listening to the controls also surfacing events or being Subjects that are observed by the Form's Interactor.
If you try to pass interaction from a top level Interactor to sub-Interactors, then this, I believe, is the wrong way round. Interactors are reactive, not proactive and only listen for Gestures rather than generating them, which is what passing control to sub-Interactors from a top level Interactor would imply.
Now, within any Interactor system, there needs to be the ability to start an interaction from one control to end in another, as in drag-dropping from a control on one form to a control on another form. This involves the use of a ScrapItem which is passed to an application scope "Scrapboard" (clipboard) by the Interactor of the originating control and then picked up by the Interactor of the target control when it detects a MouseOver message with the mouse button pressed.
I think you are trying to design how to detect when a Control gains focus, either by mouse or keypress.
Mouse activation is accomplished by using the Interactor attached to the Control receiving focus to detect the mouse click; this Interactor also publishes an event picked up by the Form's Interactor, which then sets focus to the clicked Control.
Using the Tab key to move between Controls means picking up the Tab keypress in the currently focused Control and publishing this as an event which is picked up by the Form Interactor.
You also have to bear in mind that most Windows controls already have a mechanism for handling control focus change and interfering with this could be more hassle than it is worth. It would be better to activate a Control's Interactor on a SetFocus message and deactivate it on KillFocus message.
Do these ramblings answer your questions, or am I missing your point ?
From: "Joanna Carter"
Date: Sat, 9 Feb 2002 14:27:48 -0000
Local: Sat, Feb 9 2002 10:27 pm
Subject: Re: Model View Presenter
Interactor is a specialised Handler and as such is usually held in the Presenter. The main difference between a Handler and an Interactor is that an Interactor usually copes with a timeline and is usually some kind of state machine.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Thu, 27 Nov 2003 10:01:46 -0000
Local: Thurs, Nov 27 2003 6:01 pm
Subject: Re: Feedback from a Selection
As you may have gathered, I use Interactors to respond to user gestures and these are responsible for telling the Selection to change.
Because an Interactor can be a State Machine, you can detect whether the Ctrl and/or Shift keys are pressed and Clear/Add/Replace the Selection accordingly from an appropriate State class of the Interactor.
Once the Selection has changed, the Model should then notify any Observers.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Mon, 24 Nov 2003 09:35:34 -0000
Local: Mon, Nov 24 2003 5:35 pm
Subject: Re: Linkage between Interactor, Commands and the Selection
Buttons on a form can be used in at least two different contexts:
1. They can be used to invoke Commands on the Model that is being presented in the form and, in that case, should be hooked up directly to Commands.
2. They can be used to spawn other Presenters that will display other aspects of the Model e.g. you are displaying a Customer and you want to display a list of all their Orders; The Order List is not a property of the Customer, but displaying the list is a facet of presenting a Customer.
I would hook such buttons up to simple event handlers within the Presenter for the object being displayed in the form.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Mon, 24 Jan 2005 17:12:15 -0000
Local: Tues, Jan 25 2005 1:12 am
Subject: Re: Validate data between Model and Controller in MVC
The real difference between MVC and MVP is that the 'message flow' is handled via two different 'channels', one for each direction.
The user makes a Gesture in the View
An Interactor responds to that Gesture (that Interactor may delegate reponsibility to nested Interactors, dependent on the complexity of the Gesture).
If that Gesture is intended to alter the visual selection in the View, the Interactor notifies the Selection in the Model.
Changes to the Selection are observed but he View and it is updated to match.
The Selection then notifies any Observers, one of which will be the View which will update itself accordingly, the other is the Command Set.
The Command Set updates itself based on the Selection to accomodate things like Commands not being available when more than one/only one item are/is selected.
Assuming that the Selection is now up to date, the Interactor translates subsequent Gestures, determines which Command on the Model is to be called and calls this Command.
Commands can be undone and redone and can alos support the concept of a history if required.
If executing the Command raises an exception, then the Interactor is responsible for creating a Presenter for that exception and directing the UI to a suitable focus point.
Assuming the Command succeeds, the Model, which contains the Value Type is passes the change to the Value Type.
The Value Type responds to the change by notifying any Observers, one of which would be the View.
This structure is more flexible in that Interactors and Commands can be relatively freely substituted depending on the nature of either the View or the Model.
MVPs can also be nested, so you get a MVP 'component' for a BO, the View of which will be a form, but this component will contain other MVP components, one for each of the properties of the BO, the views of which will be the edits on the form.
The inner MVP components can be created at runtime based on the names of the BO properties matching the 'PropertyName' of the relevant edit on the form.
I tend to talk about creating Presenters for Value Types; this then means that your client code usually creates/retrieves a Value Type (a BO is a composite Value Type) and then simply passes that Value Type to the constructor of a Presenter. The Presenter is responsible for creating a form or other display and will self-destruct when the form closes.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Tue, 23 Nov 2004 10:31:41 -0000
Subject: Re: Correct design ?
If you look at the articles on MVP, you will see that any forms that you create should have absolutely no code on them. Any events generated by buton or mouse clicks are handled in Interactors; thus allowing you to redisgn or replace forms without having to rewrite handler code.
It is the job of the Presenter to create an instance of an appropriate form and show it. The above code assumes that all Presenters create forms that are shown modally; you could not call Free for non-modal use, you would have an event handler in the business layer that would free off such a Presenter when the form closed.
As well as creating a form, the Presenter also populates the form from the object and hooks up the event handlers of the form to Interactor objects that respond by talking to the business object to update its state.
Newsgroups: borland.public.delphi.oodesign
From: "Joanna Carter \(TeamB\)"
Date: Thu, 2 Jun 2005 09:13:32 +0100
Local: Thurs, Jun 2 2005 4:13 pm
Subject: Re: How Interactor spawn others?
From my research, it should not be necessary to have a top level Interactor for the form if it is just to handle Buttons. Each of the buttons on a form should be wired up directly to a Command in the Model for the object being displayed on the form. In my MVP framework, Buttons implement the ICommandGuiObject, as do Menu items. Due to the simplicity of anticipated interaction between the Button and its related command, there really is no need for the complexity of an Interactor. Any Button or MenuItem should use the Observer pattern to detect when a Command is enabled/disabled; other than that, there is only the need to hold a reference to a Command in the Button and override the Click method of the Button or MenuItem to call the Execute method of the Command.
But when it comes to handling of Edits, Lists, etc; this relies on the Interactors that are listening to the controls also surfacing events or being Subjects that are observed by the Form's Interactor.
If you try to pass interaction from a top level Interactor to sub-Interactors, then this, I believe, is the wrong way round. Interactors are reactive, not proactive and only listen for Gestures rather than generating them, which is what passing control to sub-Interactors from a top level Interactor would imply.
Now, within any Interactor system, there needs to be the ability to start an interaction from one control to end in another, as in drag-dropping from a control on one form to a control on another form. This involves the use of a ScrapItem which is passed to an application scope "Scrapboard" (clipboard) by the Interactor of the originating control and then picked up by the Interactor of the target control when it detects a MouseOver message with the mouse button pressed.
I think you are trying to design how to detect when a Control gains focus, either by mouse or keypress.
Mouse activation is accomplished by using the Interactor attached to the Control receiving focus to detect the mouse click; this Interactor also publishes an event picked up by the Form's Interactor, which then sets focus to the clicked Control.
Using the Tab key to move between Controls means picking up the Tab keypress in the currently focused Control and publishing this as an event which is picked up by the Form Interactor.
You also have to bear in mind that most Windows controls already have a mechanism for handling control focus change and interfering with this could be more hassle than it is worth. It would be better to activate a Control's Interactor on a SetFocus message and deactivate it on KillFocus message.
Do these ramblings answer your questions, or am I missing your point ?
# posted by Chau Chee Yang : 12:01 AM
