search(Object criteria) - to vague?

Discussion in 'Java' started by VisionSet, Dec 3, 2004.

  1. VisionSet

    VisionSet Guest

    I have a series of input components, text fields, check boxes etc in a
    series of view subclasses.
    When a user presses search, a method collects the inputs and forwards them
    to a controllers search(Object criteria) method.
    So it may get a String[] or perhaps a single String or maybe an Object[]
    with Boolean and String etc.
    Each view has its own controller so the search method is tailored to that
    view, but it is being called via an interface method search(Object criteria)
    Is there a better way to design this? Or if this is broadly okay what is
    best practise to implement it properly, constants etc...

    TIA
    --
    Mike W
     
    VisionSet, Dec 3, 2004
    #1
    1. Advertising

  2. VisionSet wrote:

    > I have a series of input components, text fields, check boxes etc in a
    > series of view subclasses.
    > When a user presses search, a method collects the inputs and forwards them
    > to a controllers search(Object criteria) method.
    > So it may get a String[] or perhaps a single String or maybe an Object[]
    > with Boolean and String etc.
    > Each view has its own controller so the search method is tailored to that
    > view, but it is being called via an interface method search(Object criteria)
    > Is there a better way to design this?


    Sounds to me like you might be able to apply generics and type-parametrize the
    search method.
     
    Michael Borgwardt, Dec 3, 2004
    #2
    1. Advertising

  3. VisionSet wrote:

    > I have a series of input components, text fields, check boxes etc in a
    > series of view subclasses.
    > When a user presses search, a method collects the inputs and forwards them
    > to a controllers search(Object criteria) method.
    > So it may get a String[] or perhaps a single String or maybe an Object[]
    > with Boolean and String etc.
    > Each view has its own controller so the search method is tailored to that
    > view, but it is being called via an interface method search(Object criteria)
    > Is there a better way to design this? Or if this is broadly okay what is
    > best practise to implement it properly, constants etc...


    I would not be comfortable with that. I would at least want something
    along the lines of

    interface SearchCriteria {
    List asList();
    }

    abstract class AbstractController {
    <some return type> search(SearchCriteria criteria);
    }

    The specific details of the SearchCriteria interface are not much
    relevant -- you could even reduce it to a tag interface if that suits
    you. The point is to apply at least a minimum level of type safety, so
    if you are using 1.5 then Michael's suggestion of applying generics to
    the problem might be a better solution.


    John Bollinger
     
    John C. Bollinger, Dec 3, 2004
    #3
  4. VisionSet

    VisionSet Guest

    "John C. Bollinger" <> wrote in message
    news:copqo7$oke$...

    > I would not be comfortable with that. I would at least want something
    > along the lines of
    >
    > interface SearchCriteria {
    > List asList();
    > }
    >
    > abstract class AbstractController {
    > <some return type> search(SearchCriteria criteria);
    > }
    >
    > The specific details of the SearchCriteria interface are not much
    > relevant -- you could even reduce it to a tag interface if that suits
    > you. The point is to apply at least a minimum level of type safety, so
    > if you are using 1.5 then Michael's suggestion of applying generics to
    > the problem might be a better solution.
    >


    mmm,
    Lets introduce the DAO in to the picture.

    View calls controller with some specific criteria that the controller makes
    sense of because it is the client of the view. It then formats it correctly
    to request results from the DAO. What responsibilities does the concrete
    SearchCriteria class have?

    The controller can do searchCriteria.asDAOCriteria()
    could return a String[], this puts DAO knowledge onus on the SearchCriteria
    class.

    That sort of thing okay?

    --
    Mike W
     
    VisionSet, Dec 3, 2004
    #4
  5. VisionSet wrote:

    > "John C. Bollinger" <> wrote in message
    > news:copqo7$oke$...
    >
    >
    >>I would not be comfortable with that. I would at least want something
    >>along the lines of
    >>
    >>interface SearchCriteria {
    >> List asList();
    >>}
    >>
    >>abstract class AbstractController {
    >> <some return type> search(SearchCriteria criteria);
    >>}
    >>
    >>The specific details of the SearchCriteria interface are not much
    >>relevant -- you could even reduce it to a tag interface if that suits
    >>you. The point is to apply at least a minimum level of type safety, so
    >>if you are using 1.5 then Michael's suggestion of applying generics to
    >>the problem might be a better solution.
    >>

    >
    >
    > mmm,
    > Lets introduce the DAO in to the picture.
    >
    > View calls controller with some specific criteria that the controller makes
    > sense of because it is the client of the view. It then formats it correctly
    > to request results from the DAO. What responsibilities does the concrete
    > SearchCriteria class have?


    I had originally envisioned it merely is a specifically-typed container
    for the criterion object(s), in which role it has no more responsibility
    than the Object that you were already using.

    > The controller can do searchCriteria.asDAOCriteria()
    > could return a String[], this puts DAO knowledge onus on the SearchCriteria
    > class.
    >
    > That sort of thing okay?


    I started to write something about nesting the search criterion class
    within the controller, and then realized that that would make it
    difficult for the class to fulfill its original role. I then started to
    write something about MVC, just to realize that too much Swing has
    polluted my thinking about the roles of M, V, and C and their interplay.
    Swing welds view and controller together, which makes sense in some
    ways, but which also does contribute to confusion. Having now purified
    myself, I proceed.

    It boils down to this: any user request is conceptually issued to the
    _controller_ not to the view. It is then important to recognize that
    the model presented by the view in a typical application is compound:
    there is generally some application data, but there is also *an
    interface to the controller*, which may include arbitrary data. When
    the user requests some action by twiddling a knob (presented by the
    view), the controller should be notified only of the details specific to
    that twiddle. It is then the _controller_'s responsibility to extract
    whatever information it needs from the context of the action (including
    the model) to fulfill the user request.

    The answer to the original question, then, is that you're going about it
    the wrong way, and that's part of why you're having difficulty. My
    original answer was off the mark because I misidentified the problem.

    Model, view, and controller do need to be properly matched, so if you
    want to provide a search mechanism in a generic MVC setup then it is
    reasonable to stipulate that each component generate and consume objects
    compatible with the other components. To this end, then, a reasonable
    paradigm might be:

    abstract class AbstractController {
    void performSearch(); // obtains the criteria from the model
    /* or
    * void performSearch(AbstractModel m);
    * if the extra context is necessary
    */

    [...]
    }

    abstract class AbstractModel {
    SearchCriteria getSearchCriteria();
    }

    The view is responsible for invoking the controller's performSearch()
    method when it's (the view's) "Search" control is activated. Presumably
    the view also presents a some kind of form for entering search criteria;
    when a modification to the form is committed the controller is invoked
    to update the form model, thus making the data available for when the
    search is requested.

    This paradigm could be implemented with use of Generics if you're using
    Java 1.5, but beware of the overriding vs. overloading difficulty that
    Michael Borgwardt recently raised in this forum.


    John Bollinger
     
    John C. Bollinger, Dec 6, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VisionSet
    Replies:
    2
    Views:
    316
    VisionSet
    Oct 28, 2004
  2. akennis
    Replies:
    7
    Views:
    767
    Peter
    Jul 26, 2006
  3. Chad

    vague lvalue vs rvalue question

    Chad, Apr 16, 2008, in forum: C Programming
    Replies:
    0
    Views:
    256
  4. Bill Youngman
    Replies:
    1
    Views:
    191
    Bill Youngman
    Oct 11, 2005
  5. Franklin H.

    A couple of vague LWP questions

    Franklin H., Apr 25, 2005, in forum: Perl Misc
    Replies:
    7
    Views:
    121
    Joe Smith
    Apr 25, 2005
Loading...

Share This Page