Refactoring Suggested Items. List Logic

The next goal is a big one, refactor the display of items from the DataFetchController into a separate class. The reasons behind this refactoring are:

1. This is a common task which needs to be performed frequently. Anytime you find yourself pasting in a set of similar methods, you really should consider refactoring that.
2. This is a more object oriented approach, and favors composition over inheritance. This allows for smaller sets of objects to work together. Every sample class I see usually has the view controller implementing the UITableViewDelegate and the UITableViewDataSource. I want to factor these out into a set of common classes that can work together.
3. Currently I'm targeting IPhone OS 3.0 or greater since I'm using core data. At some point I might want to target earlier versions of the OS. In this case I would need to work with arrays instead of core data objects. In addition I can switch between using relationship properties, and queries with minimal effort.
4. As I learn more about the framework, additional capabilities can be backfilled into earlier projects by changing the base classes. [Note that this does add additional testing time when I make changes].

The design:

The top layer of this will be a container class that encapsulates a set of strategies. This is basically a template design pattern with individual strategies for certain tasks.    These strategies will be 4 protocols which define the behavior characteristics. The first version of implementing these protocols will be simple. In addition various implementations will have different capabilities rhey might support. Instead of implementing these in every class we will define additional protocols that define this behavior

JLTableContainer

This is the template object that contains the other sources.  It will contain utility routines that enable you to quickly create common tables, and configure their behavior.  The initial version will be rather thin, just the existing fetched controller behavior, but additional functionality will be added as the libraries mature.

JLTableSource

This implements the UITableViewDataSource protocol and defines methods that determine which data items are available. This will probably have very few methods other than properties for the other members of the hierarchy.

Initial subclasses will be:

• JLFetchedControllerSource -- Implements a wrapper around a fetch controller.
• JLSetArrayController -- Implements a wrapper around a set or array.

JLCellProvider

This is a very specific class that given a given index path provides the cell for this index.

Initial subclasses will include:

• JLKeyValueCellProvider -- Provides a value based on a key from the object.
• JLDescriptionProvider -- Uses the standard NSObject description method as text.
• JLSelectionProvider -- Provides a checkbox and monitors it's behavior. This will also implement the callbacks as well.

JLCallbackHandler

This is a wrapper around the common actions, such as selecting an accessor or cell, and then performing an action. It will encapsulate the association of the action with a specific object, and then call the JLTableController to actually do the action.

Initial subclasses will include:

• JLStandardCallbacks -- Delegate the standard callbacks to the designated list.
• JLSelectionProvider -- Encapsulate a class that tracks selections/deselection in combination with the cell provider.

JLTableController

This is the domain class that acts upon choices. It implements the UITableViewDelegate It provides methods that respond to the choices the user made, and potentially provides methods for controlling a navigation bar or control bar, or a search bar.

Initial versions:

• JLSelectionProvider -- A base class for doing selections.
• JLTableSearcher -- Searching through a list for values.