Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
122 lines (93 sloc) 4.45 KB
The major design is that of a connected model & controller. No view (as in
MVC) is needed because the data that is modelled will never change--it's
information about types, which must be static (or the CLR gets mad).
The main problem (at this point) is one of future directions: I'd like to have
a GUI front-end. Ideally, the GUI and console front-ends would use the same
internal representation, which we could format as desired (e.g. format for
different languages such as C#, Visual Basic, CLOS, Eiffel, etc.).
GUI Issues:
Additionally, with the GUI we don't want the entire tree to be generated --
that would take too long. We want sub-nodes to be expanded only when required
(the user clicks on them), and not sooner.
The GUI actually becomes the most complicated design consideration. If we
have a tree, we need to show to the user that the tree can be expanded by
having a `+' next to it. This is typically done by having sub-nodes under the
node to click. But these are the nodes we want to avoid displaying!
I can think of two solutions to this: show them anyway, but not *their*
children (so we only need to generate two levels when starting -- the
top-level elements and their immediate children). We thus always have the
children -- permitting (somewhat) rapid expansion of tree nodes, but when the
children are displayed we'll have to grab the grand-children.
Alternatively, instead of having the children available, we have a single
placeholder available, and the first time the `+' is clicked we remove the
placeholder and generate the immediate children that should be displayed.
The problem with either of these approaches is that it requires that type
displaying be interruptable. The 0.2 version had it simpler -- it would
stream the type information to the console, following all children as it found
them. This was simple, but it didn't permit a GUI view.
Hopefully, all of these issues can be handled in the design below.
I would like to retain the current 0.2 behavior of categorizing the output,
where a category would be Fields, Methods, Properties, Constructors, etc.
The question becomes: how is this supported? We want (e.g.) all interfaces to
be grouped together; who maintains the grouping?
Answer: NodeGrouper.
A node is an element in a tree hierarchy. In a GUI, it would be the
underyling dat for an item in a tree-view (hierarchical display widget).
It has a display string. It has sub-nodes (children). It also has an
associated `object' which could be used for
additional output possibilities. (This isn't explored very far, but I can see
it as being useful. The `object' would be a Type instance for class names, a
`MemberInfo' for members, etc.)
Nodes have three classes associated with them: a NodeFormatter, which formats
the display string described above. It also has a NodeFinder object, which is
used to determine which sub-nodes will be displayed. Finally, it has a
NodeInfo instance, which collects various information about the node such as
its type (NodeTypes) and related information.
The NodeInfo type is used as the sole communication between NodeFinder and
NodeFormatter. A NodeFinder returns a collection of NodeInfo objects, each of
which is sent to the NodeFormatter object before being displayed.
Categorization can be done through "decorators" (see GoF) on the NodeFinder.
Controller [View]
\ /
\ /
/ | \
/ | \
INodeFormatter INode- NodeInfo
- GUI App, Console Main program
-- Controls output, display
- Display device for Nodes.
- Note quite MVC; there's no feedback mechanism so that Views change when
the Node changes
- Nodes can't change; the type system is static
- However, this could be added in the future if necessary.
Node (Model)
- Members:
- string Description {get; set;}
-- The display string
- NodeInfo NodeInfo {get;}
-- Information about this node
- NodeCollection GetChildren ();
-- Returns the sub-nodes of this node
-- Formats a node for output (particular language, etc.)
- Methods:
- string GetDescription (NodeInfo)
- LanguageFormatter
- CSharpFormatter, ...
-- Decides which children are present
- Members:
- NodeInfoCollection GetChildren(NodeInfo);
Something went wrong with that request. Please try again.