wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Flexible search system.. doing too much? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Flexible search system.. doing too much?" Watch "Flexible search system.. doing too much?" New topic
Author

Flexible search system.. doing too much?

Jo�o Batista
Ranch Hand

Joined: May 25, 2008
Posts: 40
Hi,

The thread about patterns got me thinking if I overdeveloped the flexible search system.

Instead of find(Criteria criteria), I provided a find(Criteria criteria, CriteriaFilter[] filters).

The GUI controller can create any object for filtering the search. This way I could combine inexact and exact searches in a CriteriaFilter implementation (since I used an editable combobox for that).

I, myself, do not think it is complex, and the documentation is simple as well. Would this approach be too much for the "flexible system"?

Thanks.
Ewan Livingstone
Greenhorn

Joined: Jun 16, 2008
Posts: 14
My interface is similar to yours. Probably won't get us any more marks than just implementing some find(String[] criteria, boolean exact) type method, but it's good clean geeky fun and interesting to experiment with...
Soroj Margun
Ranch Hand

Joined: Jun 15, 2008
Posts: 44
Hi,

I think it's a little bit too much but if it make your program more easier then nothing wrong with it


SCJP 1.2; SCWCD 1.2,1.4; SCBCD 1.3; SCJD 5.0
Jo�o Batista
Ranch Hand

Joined: May 25, 2008
Posts: 40
Glad to see others having similar approaches.

It does make the search flexible (as the requirements expect). What I think it's extra in my case is implementing any other filters.
I configure a filter in less than 10 lines (because it depends on the selected comboboxes), and they are simple (as the requirements expect).

It was indeed geek fun making it, and I'm sticking with it!
Chih-Wei Lee
Ranch Hand

Joined: Feb 20, 2008
Posts: 129
Not at all,
I think a criteria filter is necessary
because the difference between UI requirement and DB interface definition.
UI needs a exact matched result.
However, the find method definition asks us return the records with the field value beginning from criteria.
If you want to fit both needs, you need a filter.


SCEA, SCJD, SCDJWS, SCWCD, SCJP
Jason Moors
Ranch Hand

Joined: Dec 04, 2001
Posts: 188
Hi,

As long as you feel you can justify in your design decisions I think you'll be fine. Just remember that you are not allowed modify the existing find method signature of the interface, so you should add as an additional find method!!!

In my opinion it's not necessary and adds complexity, having said that many people have past the exam by implmenting the additional find functionality.

The requirements define two different search requirements but this doesn't mean that they both have to be implmented at the database layer. I implemented the standard find method in my data class and the exact match in my business logic layer.

It also depends on how you interpret the requirements, I only implemented the �AND� condition, so any records must match criteria for all fields that are not null.

My reason for this was that I couldn't see a sensible (or simple) way of implementing the �OR� condition with the current find method signature (without adding a new search method), and from an usability perspective it didn't make sense to me to support a search where you could allow the user to select a name of a hotel OR and location.

Jason
Jo�o Batista
Ranch Hand

Joined: May 25, 2008
Posts: 40

Just remember that you are not allowed modify the existing find method signature of the interface, so you should add as an additional find method!!!

The requirements define two different search requirements but this doesn't mean that they both have to be implmented at the database layer. I implemented the standard find method in my data class and the exact match in my business logic layer.


My bad. I did not tell that that find signature belongs to my business layer. My implementation is similar to yours. The find in Data is implemented following DBMain. It felt cleaner to add these filters in the business layer.



It also depends on how you interpret the requirements, I only implemented the �AND� condition, so any records must match criteria for all fields that are not null.

My reason for this was that I couldn't see a sensible (or simple) way of implementing the �OR� condition with the current find method signature (without adding a new search method), and from an usability perspective it didn't make sense to me to support a search where you could allow the user to select a name of a hotel OR and location.

Yes, I interpreted the OR as allowing to search either by hotel only or city only. Since I am following DBMain, that, along with what you said, was the reason to not add that functionality to Data.

Thanks for the reply.
I think it is time to wrap things up and upload it already!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Flexible search system.. doing too much?
 
Similar Threads
B&S- Find method
Handling the criteria in a business layer
Another MUST requirement interpretation question
Wrap a record class
case sensitive or not