Externalize search functionality into separate class from HeaderFinderBox to better handle shared knowledge

Issue #252 new
Christopher Keil repo owner created an issue

[EDIT: Split this issue into 2; this one and issue #282]

One HeaderFinderBox should not know about the other and be strictly about the HeaderFinderBox as a GUI object.

The search code should be externalized into a SearchHandler class which knows about the state and content of both HeaderFinderBoxes (via reference and appropriate state query methods). This way knowledge about the state/ data of both axes can be delegated well.

Comments (8)

  1. Robert Leach

    I recall, when we last spoke about this issue in a meeting, we had concluded that implementing a single search box was difficult enough that we wouldn't require it for alpha03. The difficulty lies in how to specify a different search term for rows versus columns together as a combined search. We talked about how it could behave like a filter that a user could dismiss by clicking an 'x' or something but that that would be difficult to implement.

    So instead, we agreed, for alpha03, to use the 2 search boxes and have each search utilize the contents of each box.

    As it relates to this issue where the number of headers loaded is a bug, I have looked at the code and I think that what could be done would be to retrieve the min & max selected index from the selection instead of doing it using the set of headers inside the HeaderFinderBox class. That fix should be fairly straight-forward.

  2. Robert Leach

    I separated the enhancement portion of this issue from the bug portion and increased the bug priority to critical (and this enhancement to minor - feel free to adjust).

  3. Robert Leach

    Since the implementation of the companionbox member, perhaps this issue is no longer necessary/called for?

  4. Christopher Keil reporter

    Probably not since #282 was resolved and the problem of search boxes not knowing some important things about each other was solved. I do prefer top level delegation of some data over the two objects directly referring to each other but I think we have far more pressing matters. Maybe we should put this on hold in case similar issues pop up?

  5. Log in to comment