[tssg-tech] Re: research on Adapters (what, why, when and how)

From: Sanghamitra Chowdhury <sanghirc@xxxxxxxxx>
To: tssg-tech@xxxxxxxxxxxxx, harry_henriques@xxxxxxxxxxx
Date: Mon, 1 Nov 2010 10:18:40 -0400
This is Sanghamitra. The Android work sounds really interesting and is going
forward very well. I have been busy for a while working as a consultant. As
that contract is drawing to an end, I would love to participate in the
Android work with your help. Will probably be there for this Wednesday's
meeting.

Thanks,
Sanghamitra.

On Fri, Oct 29, 2010 at 6:27 PM, Harry Henriques <
harry_henriques@xxxxxxxxxxx> wrote:

>  Hello team,
>
> We probably should use the "Passive Model" that is explained below.   I
> think that our architecture would look like this:
>
> BTW, I realize that our application isn't a strict HTTP request/response
> model
> Passive Model
>
> With a passive model, the objects used in the model are completely unaware
> of being used in the MVC triad. The controller notifies the view when it
> executes an operation on the model that will require the view to be
> updated.  The passive model is commonly used in web MVC. The strict
> request/response cycle of HTTP does not require the immediacy of an active
> model. The view is always completely re-rendered on every cycle,regardless of 
> changes. This may be especially true in
> PHP where no state is retained between requests.
>
>
> ________________
> |               |
> | DataStore     |
> | MODEL         |
> |persist data   |
> |---------------|
> | Data Buffer   |------|
> --------^--------      |
>   find  | store        |
> __data__|_data____     |
> |                |     |
> |  RSS Parser    |     |
> |  CONTROLLER    |     |retrieve data
> |                |     |
> ----------^-------     |
> update|   | issue      |
> view  |   | requests   |
> ------V-----------     |
> |                |     |
> | User Interface |<-----
> |     VIEW       |
> |                |
> ------------------
>
> If I understand the passive MVC design pattern, the following operations
> occur in sequence:
>
> (1) A widget in the VIEW is activated.  It sends a message to the
> CONTROLLER, e.g. "get RSS feed"
> (2) The CONTROLLER responds by sending a message to the MODEL, e.g. "change
> stored data".
> (3) Simultaneously, the CONTROLLER notifies the VIEW that the "stored data
> has changed"
> (4) The VIEW responds by retrieving data from the MODEL and populating the
> presentation layer.
>
> The MODEL doesn't know anything about the VIEW.  The MODEL exposes methods
> that allow the CONTROLLER to store data from the RSS Parser, and exposes
> methods that allow the VIEW to retrieve data from it.  The MODEL is
> completely PASSIVE in this architecture; it is completely uncoupled from the
> CONTROLLER and the VIEW.
>
> Let me know if we agree if this is actually the MVC pattern that we are
> talking about.  I don't think we need a ADAPTER unless we are forced to
> implement an ACTIVE MODEL.
>
> Best regards,
> Harry Henriques
>
>
>
>
> Model View Controller
>
> Model View Controller MVC is a time tested method of separating the user
> interface of an application from its Domain 
> Logic<http://www.phpwact.org/pattern/domain_logic>.
> The primary goal of MVC is to isolate UI changes and prevent them from
> requiring changes to the Domain 
> Logic<http://www.phpwact.org/pattern/domain_logic>of the application.  The 
> primary reason for this division is that the user
> interface and Domain Logic <http://www.phpwact.org/pattern/domain_logic>have 
> different drivers for change and different rates of change. By making
> this separation, you can change the UI without touching the Domain 
> Logic<http://www.phpwact.org/pattern/domain_logic>and vice versa.  MVC is 
> sometimes confused with other patterns that have the
> same goal of separating user interface from Domain 
> Logic<http://www.phpwact.org/pattern/domain_logic>,
> such as Presentation Abstraction 
> Control<http://www.phpwact.org/pattern/presentation_abstraction_control>.
>
>
> MVC divides an application into three concerns:
>
>    - Model - Encapsulates core application data and functionality Domain
>    Logic <http://www.phpwact.org/pattern/domain_logic>.
>    - View - obtains data from the model and presents it to the user.
>    - Controller - receives and translates input to requests on the model
>    or the view.
>
> The separation into three concerns is inspired by a information processing
> model where the controller represents system input, the model represents
> processing and the view represents the output of the system.
> Model
>
> The model encapsulates the functional core of an application, its Domain
> Logic <http://www.phpwact.org/pattern/domain_logic>. The goal of MVC is to
> make the model independent of the view and controller which together form
> the user interface of the application. An object may act as the model for
> more than one MVC triad at a time.
>
> Since the model must be independent, it cannot refer to either the view or
> controller portions of the application. The model may not hold direct
> instance variables that refer to the view or the controller. It passively
> supplies its services and data to the other layers of the application.
>
> See Domain Model <http://www.phpwact.org/pattern/domain_model> and Transaction
> Script <http://www.phpwact.org/pattern/transaction_script> to organize Domain
> Logic <http://www.phpwact.org/pattern/domain_logic>.
> Passive Model
>
> With a passive model, the objects used in the model are completely unaware
> of being used in the MVC triad. The controller notifies the view when it
> executes an operation on the model that will require the view to be updated.
>
>
> The passive model is commonly used in web MVC. The strict request/response
> cycle of HTTP does not require the immediacy of an active model. The view
> is always completely re-rendered on every cycle, regardless of changes. This
> may be especially true in PHP where no state is retained between requests.
>
> Active Model
>
> In the active model, model classes define a change notification mechanism,
> typically using the Observer 
> <http://www.phpwact.org/pattern/observer>pattern. This allows unrelated view 
> and controller components to be notified
> when the model has changed. Because these components register themselves
> with the model and the model has no knowledge of any specific view or
> controller, this does not break the independence of the model.
>
> This notification mechanism is what provides the immediate updating that is
> the hallmark of a MVC GUI application.
> Model Adapter
>
> It is possible to use an Adapter <http://www.phpwact.org/pattern/adapter>to 
> add change propagation or other active model features to passive model
> objects, turning a passive model into an active model.
>
>
>
>
> ---------------
> http://www.linkedin.com/in/harryhenriques
>
>
>
>
>  ------------------------------
> *From:* Jim Cant <cant_jim@xxxxxxxxxxx>
> *To:* tssg tech <tssg-tech@xxxxxxxxxxxxx>
> *Sent:* Fri, October 29, 2010 8:53:03 AM
> *Subject:* [tssg-tech] Re: research on Adapters (what, why, when and how)
>
> Julie's research makes the case for using 'Adaptors' in implementing a
> ModelViewControler model in Android apps; it focuses on Android.
>
> I see nothing in it that says one shouldn't use strategies such as using
> interfaces to hide the implementation of software components  to build
> modular, maintainable, reusable software.  I don't see where it argues
> against our current design for EventBoss.
>
> jim
>
> ------------------------------
> Date: Wed, 27 Oct 2010 17:33:31 -0700
> From: jcarwellos@xxxxxxxxx
> Subject: [tssg-tech] research on Adapters (what, why, when and how)
> To: tssg-tech@xxxxxxxxxxxxx
> CC: kieu.hua@xxxxxxxxx
>
> I'm attaching a Word document that has the results of my research around
> the net on Adapters - what are they, why and when to use them, how to
> implement them and use multiple adapters. I was surprised (but should not
> have been) that they are actually an implementation of the Mediator pattern.
> They are also required for AdapterViews (such as ListView and GridView).
> When you do a 'setAdapter()' on the view to change the adapter, the data in
> the list is automatically invalidated, and the list refreshes itself.
>
> The attached contains the details, links and additional information.
>
> Julie
>
> ------------------------------
> Julie (Dingee) Carwellos
> Web and IT Project Analyst, User Experience and Interaction Designer
> LinkedIn <http://www.linkedin.com/in/jdingeecarwellos> -
> http://www.linkedin.com/in/jdingeecarwellos
>
>
>


-- 

Regards,
Sanghamitra
978-697-6324
Follow-Ups:
- [tssg-tech] Testing samples checked in
  - From: Beatrice W. Chaney
[tssg-tech] Re: research on Adapters (what, why, when and how)

Other related posts:
