search(Object criteria) - to vague?

[VisionSet]

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

 

[Michael Borgwardt]

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.

 

[John C. Bollinger]

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
(e-mail address removed)

 

[VisionSet]

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?

 

[John C. Bollinger]

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
(e-mail address removed)