Difference between MVC & Front- Controller

Hi All,
could anyone help me out in differenciating the MVC & Front controller patterns.
regards
Karthik

When should an application use the Front Controller
patern and when should they use MVC? This boils down to scope of the problem domain and requirements.
The Front Controller seems largely like a subset of
MVC.Yes.
Is there a situation where the Front Controller
is more advantageous to use than MVC?Where its lighter weight pays off, i.e where you do not have a conventional model, e.g with streaming prototcol handlers or with fast readers. MVC is most useful for a N-Tier J2ee application offering CRUD type functionality.

Similar Messages

Musings: MVC Front Controller/Command and Controller Strategy

Hi,
I am currently taking my first shot at implementing the Front Controller pattern, the Command and Controller Strategy flavor, in Java. When applying the pattern, my chosen point of focus is achieving as much isolation as possible of Client-specific implementation details from the rest of the framework (Web-based framework Clients, Swing-based framework Clients, queueing-based framework Clients, etc.) However, I am running into a lot of (apparent?) inconsistencies when it comes to CCS discussions "out there", so I have a feeling that perhaps I have misunderstood the Front Controller/Command and Controller Strategy pattern. Maybe the MVC gurus out there would have some thoughts on the matter.
My issues:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?
Any comments appreciated...
Thanks,
Gary

gniemcew wrote:
1.) Some CCS discussions seem to assign View presentation (sometimes called "dispatch", or "rendering", or "forwarding"?) to an ApplicationController. It seems puzzling to me, since only a concrete FrontController should include any knowledge of a concrete View structure. Shouldn't only a FrontController perform a logical-to-physical resource mapping, thus encapsulating knowledge whether a particular View is a separate, stand-alone Web page or a compound, argument-driven Swing object, and how to "present it" (by either redirecting to a Web page, or bringing a particular Swing object into the foreground)?It is hard to tell without reading the actual discussion, but my guess is that the posters were either conflating or being loose with the distinction between a FrontController and an ApplicationController. The former is (normally) intimately tied to the actual view being used (HTTP, Swing, etc.) whereas the ApplicationController typically is not. Both are involved in dispatch and event processing. The former normally renders a view whereas the latter does not.
gniemcew wrote:
2.) Some CCS discussions seem to introduce Client-specific implementation details at the ApplicationController level, for example "HTTP requests" or "HTTP responses". It seems puzzling to me, since I feel that every part of the framework, except for a concrete FrontController, should be completely independent of the nature of a Client making a request. Instead, I created a generic Request object w/arguments and have a concrete FrontController translate any client-specific details into such a generic Request, before delegating to an ApplicationController.Generic is fine. However, you can become generic to the point where your Request and Response interfaces are only acting as "marker" interfaces (think of java.io.Serializable). Writing a truly generic controller is possible, but personally, I have never found the effort justified.
gniemcew wrote:
3.) In the light of the (2.) above, I am not sure what constitutes a "response" from an ApplicationController back to a FrontController. It seems to me that the only universal "response" is a LogicalViewEnumeration: what View to present once a command has been completed, in many cases a "don't care", or a "show the requestor", or a "show a home page" (not every request has to result in changing a View). Well, perhaps a LogicalViewEnumeration as well as possible View arguments (?).A given service (if you ascribe to SOA) should be the fundamental unit in your architectural design. A good application controller would be responsible for determining how to dispatch a given Command. Whether a Command pattern is used or whether service methods are invoked directly from your FrontController, the ApplicationController should enforce common service aspects. These include authentication, authorization, auditing, orchestration, validation, logging, error handling, just to name a few.
The ApplicationController should ideally offload these aspects from a given service. The service would indicate how the aspects are to be applied (e.g., strong authentication required, x role required, fetching of existing process state, etc.) This allows services to be developed more quickly and to have these critical aforementioned aspects developed and tested centrally.
Your FrontController, in contrast, is responsible for transforming whatever input it is designed to receive (HTTP form data posts, XML-RPC, etc.) and ensure that it honors the contract(s) that the ApplicationController establishes. There are no cut-and-dry decisions though about when a given piece of functionality should be ApplicationController or FrontController. Take error handling. Should I emit just a generic ServiceException or allow the FrontController to decide what to do with a more concrete checked exception? (The FrontController, in any case, should present the error to the user in a manner dictated by the protocol it serves).
gniemcew wrote:
4.) In the light of the (3.) above, I suspect that any failures in Request delegation, or Command execution, should be perhaps propagated back to a FrontController by exceptions only, since, say, a WebFrontController might want to show a click-through error page, when a SwingFrontController might prefer to show an error dialog box, a LogicalErrorViewEnumeration might not make sense at all in the context of a particular Client, for example a queueing Client.See above. Yes. However, the ApplicationController could easily 'hide' details about the failure. For example, any number of exceptions being mapped to a generic DataAccessException or even more abstractly to a ServiceFailureException. The ApplicationController could indicate whether the failure was recoverable and/or populate information necessary to speed up production support (e.g., mapping exceptions to error codes and/or providing a primary key in an error audit log table for support to reference). A given FrontController would present that information to the user in the method that makes sense (e.g., error dialog for Swing, error page for HTML, etc.)
gniemcew wrote:
5.) In the light of the (4.) above, there is the question of an appropriate Request interface (into an ApplicationController), an appropriate Response interface (back into a FrontController), as well as an appropriate ViewArguments interface (into a FrontController and later into a View). The problem with generic Requests is that they can be created with nonsensical argument combinations, so shouldn't Requests be abstract and force proper arguments in concrete subclasses, through explicit constructors (in a sense, degenerate Commands)? The problem with Responses and ViewArguments is that... well, I have not found any formal discussion anywhere as to what those should look like. In most samples I have encountered, Responses include Client-specific implementation details, as mentioned in (2.), above.See comment on marker interfaces above. Nothing, however, stops you from requiring a certain sub-type in a given service method. You can still pass in the interface and validate the proper type by an assert statement (after all, in the vast majority of situations, the proper service method should get the proper instance of a given Request object). IMO, the FrontController would create the Command instance which would be passed to the ApplicationController which would dispatch and invoke the proper service method. A model response would be received by the FrontController which would then render the appropriate view.
gniemcew wrote:
6.) Some CCS discussions seem to introduce a Flow Manager at the ApplicationController level. It seems puzzling to me, since the whole point of the Command and Controller Strategy flavor seems to be centralization of business logic execution within self-contained Command objects. Shouldn't Requests get associated with Handlers (objects capable of actually carrying out Requests) and transformed into Commands inside an ApplicationController, thus Commands themselves return appropriate LogicalViewEnumeration back to an ApplicationController, back to a FrontController? Let's consider a ShowMyShippingAddress request coming into the framework: unless such a Request is eventually treated as a Command returning a particular LogicalViewEnumeration, it is suddenly a Flow Manager "acting" as a business logic driver. I guess the question here is: except for a few special cases handled by a particular ApplicationController (authentication, error conditions, default behavior, etc.), should flow management be considered stand-alone, or always delegated to Commands?There are distinct kinds of flow management. For example, orchestration (or BPM) is properly at either the service or ApplicationController layers. However, determining which view to display is properly at the FrontController layer. The ApplicationController should receive a Command (with a populate Request) and return that Command (with a populated Response). Both the Request and Response are fundamentally model classes (within MVC). The FrontController is responsible for populating the Request and/or Command and rendering the Response and/or Command. Generic error handling is usually centralized for both controllers.
gniemcew wrote:
7.) Some CCS discussions seem to include an extra Request argument that specifies an ApplicationController to use (Request.Action="create", Request.Controller="account", Request.Username="me-me-me"), instead of using a Router inside of a FrontController to resolve to a particular ApplicationController through a generic action (Request.Action="createAccount", Request.Username="me-me-me"). I am not sure about the reason for such a design decision: why should a Client or a FrontController be allowed to concern itself with an implementation-level structure of the framework? Wouldn't any framework state -dependent ApplicationController resolution issues be best handled inside a Router, used by a FrontController to resolve [obtain] an appropriate ApplicationController, thus preventing Clients from ever forcing the framework into a possibly inconsistent behavior?I am not 100% sure of what you are getting at here. However, it seems to be the method by which commands are dispatched. They are in effect allowing a FrontController to dictate which of n ApplicationControllers should receive the request. If we allow a FrontController to directly invoke a service method, then the ApplicationController is simply a centralized framework that should always be invoked for each service method (enforced via AOP or some other mechanism). If there is a single, concrete ApplicationController which handles dispatch, then all FrontControllers communicate directly with that instance. It is really just a design decision (probably based on your comfort level with concepts like AOP that allow the ApplicationController to exist solely behind the scenes).
I might have totally missed your questions, but those are my thoughts on a Monday. Best of luck.
- Saish

Difference between MVC and 3-Tier model?

What is the difference between a Model View Controller design and a 3-tier design? I have read that the 3 tiers are independant, but that is also the case in the MVC design so are the two kind of designs not rather similar??

When I think of the 3-Tier system, doesn't necessarily mean hardware, but a separation of laters of logic, which may or may not be physically independent.
The 3 tiers are presentation, domain logic, and data source. When mapping these three layers to Model View Controller, the layers are not 1:1.
Presentation maps pretty close to the View, but Model encompases both the Data Source and the most of the Domain Logic. It includes how you get the data and what you do with it. The Controller is that part of the domain logic that determines a request-response control (progression from one view to the next, calling the model logic necessary along the way).

Difference between front and back camera on iphone 4s

want to know the difference between the front and back camera on my new iphone 4s the pictures don't look the same the back camera seems to take a better picture than the one facing me.

Back camera is 8 mega pixels and allows more light. Front cam is not different.

Differences between controller/view & pages with flow logic

Hi experts!!
I am trying to create a BSP using the SBOOKSHOP tutorial.
What i have not understood so far is the differnce between creating a bsp with pages with flow logic,
and using the controller/ view method.
When should we use the first and when the other approach??
Any link to documentation would be appreciated!
Thank you!!

Hi Grigoria Koutsogianni,
I hope the older thread on the same topic could help you understand the difference!
1. Re: Understanding easy BSP development (MVC vs. Flow Logic and more...)
2. Re: diffrence between MVC and Classical Bsp application
-Maheswaran

Difference Between Using MVC And SwingUtilities For GUI Component Update

Hi Guys,
What are the difference of using the MVC (Model View Controler) pattern to update GUI and using the SwingUtilities of doing the same job?
Are there any big differences or shortcomings of any?
Thanks.

kap wrote:
Hi Guys,
What are the difference of using the MVC (Model View Controler) pattern to update GUI and using the SwingUtilities of doing the same job?
Are there any big differences or shortcomings of any?
Thanks.Your question is akin to asking, "What's the difference between using a car to get somewhere versus stepping on the gas pedal to do the same job?"
The use of SwingUtilities to update the "view" only pertains to updating components in a thread-safe manner, it has nothing to do with MVC. MVC would govern when the view gets updated (i.e. after the model changes), while SwingUtilties would be used to specify how the view gets updated.

Difference between component controller & Custom controller

Hi all
what is the main difference b/w component controller , custom controller & interface controller.
i want to know the difference of these three in the real time environment.
if anybody explains me with any simple example then it is great help to me....
Thanks
Suresh babu.

Hi Suresh,
Component Controller and Custom Controller are more or less the same. Both are related to a particular component in the webdynpro application you create.
Component Controller:-
For each component of yours there will be a component controller, were in you can define context variables and methods, events etc.. This usefull while using models.
Simple example where we can see this is, when you create global context variable in this controller and map this variable to the view controller context variable of different view, which enables you to pass the value of the variable from one view to another.
Custome Controller:-
They also have the same the function but as the name suggest there function can be customised. That is we can have more than one custom controller for a component. This is usefull when we need to create seperate execute methods for inputs from model import( Both webservice and rfc call).So you can seperate each other. Example is there in the more sample codes and application section.
Interface Controller:
There is only one interface controller for a component. It is mainly used when we need to communicate between two components.There is sample application for communication between two components in the sample codes and application section.
Regards
Sreedhar.

Difference between custom controller and component controller

Hi All,
I am a beginner in CRM SAP .
Please can anyone tell me whats the difference between custom controller and component controller with some scenario.
I am totally baffled.
Thanks in advance.
Regards
Shilpi

Hi Shilpi,
The main difference between custom and component controller is the role which they play during data transfer.
a) Custom controller is used for data transfer across two views within a component. For that you need to bind view context nodes to custom controller either through wizard or manually by adding the code in CTXT class create_contextnode method:
initial setting for depandant model node
    coll_wrapper =
      BTADMINH->get_collection_wrapper( ).
    TRY.
        entity ?= coll_wrapper->get_current( ).
      CATCH cx_sy_move_cast_error.
    ENDTRY.
    IF entity IS BOUND.
      BTOpportH->on_new_focus(
                   focus_bo = entity ).
    ENDIF.
b)Component controller is used for data transfer across two views in two different components. For this, we need to define the component usage first and then bind the context nodes in the method-WD_USAGE_INITIALIZE of the Component Controller impl class.
    WHEN 'ComponentUsageName'.
      iv_usage->bind_context_node(
                  iv_controller_type = cl_bsp_wd_controller=>co_type_custom
                  iv_target_node_name = 'ContextNodeName' "#EC NOTEXT
                  iv_node_2_bind      = 'ContextNodeName' ). "#EC NOTEXT
Hope this clears some of your doubts!
Thanks and Regards,
Rohit
P.S-This is valid for CRM 2007.Raghu is also right because Interaction Center is made up of different different components combined together.You have put your question in wrong forum.

What is the difference between Custom controller and context controller?

Hi Gurus,
What is the difference between Custom and context controller?
In which occasion we should prefer to use Custom Controller?
Thanks in Advance,
Dharani

You mean difference between custom controller and component controller???
if yes...
its been discussed many times.... just go through these threads, you will be clear
custom controller vs component controller
Component Controller and Custom comtroller
[ why we need Custom controllers in Model Applications |why we need Custom controllers in Model Applications;
[CONTROLLER AND CONTEXT|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/944ea9e5-0601-0010-65b3-b49a56eb6385]
Pradeep
Edited by: pradeep bondla on Jul 22, 2008 12:42 PM

Difference between Component Controller and Custom Controllet...?

Hi
Can any one tell me Difference between Component Controller and Custom Controllet...?
Best Regards
Ravi Shankar B

Hi RaviShankar B,
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webas/web%20dynpro%20sample%20applications%20and%20tutorials.htm
Also refer to the below link
Component and custom controllers
Component Controller:-
For each component of yours there will be a component controller, were in you can define context variables and methods, events etc.. This usefull while using models.
Simple example where we can see this is, when you create global context variable in this controller and map this variable to the view controller context variable of different view, which enables you to pass the value of the variable from one view to another.
Custom Controller:-
They also have the same the function but as the name suggest there function can be customised. That is we can have more than one custom controller for a component. This is usefull when we need to create seperate execute methods for inputs from model import( Both webservice and rfc call).So you can seperate each other. Example is there in the more sample codes and application section.
regards
Anil Dichpally

Difference between interface view and interface controller

Hi,
What is the difference between interface controller and interface view?
When we will use interface controller and when we will use interface view?
How do we create an interface view?
How do we attach this interface view to a view in another component
Regards
MQ

Hi
Interface View Controllers
A) Implement event handlers which are called when ..
-starting (start-up plugs) Web Dypro applications
-a component is reached via navigation (inbound plugs)
B) Allow fireing outbound plugs (navigation)
C) Allow firing exit plug
D) Have no own context, public methods or events
Interface Controller of a Component
The interface controller of a Web Dynpro component contains all context nodes, events and methods of the component controller to which you assigned the Interface addition in the Controller Editor. These parts can be displayed in the interface controller view, although you cannot edit them here.
Interface Controller of a Component Interface
A Web Dynpro component interface can be created independently and defined so that it can be implemented later in any components (see working with Web Dynpro Component Interfaces in the Programming Manual of this documentation). That is why in this case you can define the context nodes, methods and events you require in the interface controller view. The relevant implementation then takes place in the component controller of the implementing component.
Check this links and work on it.
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/webcontent/uuid/28113de9-0601-0010-71a3-c87806865f26?rid=/library/uuid/49f2ea90-0201-0010-ce8e-de18b94aee2d#13 [original link is broken]
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/webcontent/uuid/28113de9-0601-0010-71a3-c87806865f26?rid=/library/uuid/49f2ea90-0201-0010-ce8e-de18b94aee2d#12 [original link is broken]
Interface view and interface controller
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f727d100-0801-0010-4cbd-b0ad5c161945
Difference between custom controller and interface component
Thanks and Regards,
Tulasi Palnati

Difference between custom controller and interface component

Hi,
Can anybody tell me what are the differences between component controller and custome controller , component interface.
Thanks in advance.
Regards
sireesha.

hi,
When any component is created web dynpro framework automatically generates the controller(controller is nothing but entity which controls the working of views and acts as a binding layer between model and view), this controller is called Component controller.
We can have as many controller as we want, but they should be used sparingly, Controller should encapsulate the functionality which is common to whole component , like if your application fetches master data and appliaction data so better you should have 2 controller , 1 for master and 2 for application so as to have modularisation in your application.
Component Interface is the entity which is used when you want to use the functionality defined in some other component i.e. if your main component is acting as a parent comopnent then the child component usage should be defined via this interface controller under Component Interface, so that main compo will access it via childs Interface Controller.
Other node under this , Interface view , gets generated for every creation of window , Interface view is entry point into our application for web Dynpro framework
jsut check out following links,
Re: Difference between Component Controller and Custom Controllet...?
Re: custom vs component controller
check out these ex for the Component Interface and node under this,
https://www.sdn.sap.com/irj/sdn/downloaditem?rid=/webcontent/uuid/19e6e990-0201-0010-eca6-a62e342eaad3 [original link is broken]
https://www.sdn.sap.com/irj/sdn/downloaditem?rid=/webcontent/uuid/1208c2cd-0401-0010-4ab6-f4736074acc6 [original link is broken]
https://www.sdn.sap.com/irj/sdn/downloaditem?rid=/webcontent/uuid/1ee0e990-0201-0010-75bf-a087c241cb83 [original link is broken]
hope it helps
regards

What is the difference between using the command "dsmgmt" and the "Managed By" tab when adding users to the local administrators Account on a Read-Only Domain Controller?

When I use the
"dsmgmt" command to add a user to the local administrators account of a RODC I can actually see the user when I use the "Show Role Administrators" parameter. However, I can't see the members of the
group added to the "Managed By" tab of the RODC object in AD. Even though, the users added using
"dsmgmt" and by the "Managed By" tab can all log in locally and have admin rights to the RODC. Are there any differences between these two ways of adding users to the local administrators account?

Hi,
For groups, managedBy is an administrative convenience to designate “group admins”. Whatever principal listed in
managedBy gets permission to update a group’s membership (the actual security is updated on the group’s AD object to allow this).
In Win2008 and later managedBy also became the way you delegated local administration on an RODC, allowing branch admins to install patches, manage shares, etc. (http://technet.microsoft.com/en-us/library/cc755310(WS.10).aspx).
On the RODC, this is updating the RepairAdmin registry value within RODCRoles.
So the difference between them should be only the way they do the same thing.
For more details, please refer to the below article:
http://blogs.technet.com/b/askds/archive/2011/06/24/friday-mail-sack-wahoo-edition.aspx
We
are trying to better understand customer views on social support experience, so your participation in this
interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

Please give the diagrams to explain the difference between MVC1 and MVC2

Please give the functional diagrams to explain the difference between MVC1 and MVC2

there is no MVC1 or MVC2, only the MVC pattern. The implementation of the MVC is fairly open-ended and there are some variations that are not named as different "versions" because each variation still has the same pattern: there is a model, there are views and there are controllers. What you list as a "feature" of MVC2 in your other post:
http://forum.java.sun.com/thread.jspa?threadID=719812&tstart=0
is merely the implementation of a front controller (becoming more popular nowadays) in stead of using multiple controllers. There is no change in pattern, only in implementation.

What is the difference between ERP2004 and SAP 47 Enterprise?

Currently we have SAP 47 Enterprise with WAS 6.2. I understand ERP2004 is NW and 6.4 sp9. Can any one please let me know the major difference between ERP2004 and SAP 4.7 Enterprise ( more from abap / workflow view)?
Thanks
Swamy

From Abap point of view some of the major add-on in erp2004,netwever :
1) Development of webdynpro studio for java development for portal and iviews.
2) Major abap development uses <b>Abap object oriented</b> methodology, rathet hten old conventional Abap,i.e MVC model (Model,View,Controller) where in it uses concept of classes,interfaces,etc.
3) Advanced BSP tech using MVC model to develop web based modules
4) It is closesly integrated with web-based CRM and BW/APO

Difference between MVC & Front- Controller

Similar Messages

Maybe you are looking for