|Home >> All|
|||jbreport.core.* (25)||||jbreport.data.* (9)||||jbreport.interfaces.* (1)|
|||jbreport.interfaces.servlet.* (1)||||jbreport.render.* (1)||||jbreport.test.* (5)|
jbreport: Javadoc index of package jbreport.
jbreport.test: This package defines the public interface to the reporting library, and should enable any developer to define their own reports using just this API.
QueryResult: This interface is meant as a thin wrapper over classes like resultsets. This is done so that we can perform actions such as aggregations without having to re-implement a monster interface... Having implemented java.sql.ResultSet before, believe me, it is no fun. This interface should provide for a class to register itself, and be called on certain actions. This is done with the registerBreakListener(jbreport.util.BreakEventListener, jbreport.util.ReportBreak) 55 method As a report does not require fancy tricks like scrolling backwards over the dataset, we only have a next() method for iteration. ...
DefaultXMLParseHandler: This is the default xml parser handling class. It is registered with the actual sax parser, and will receive the appropriate callbacks. It should not know about concrete implementations of reporting elements, it should just make the appropriate calls to the ReportElementFactory instance. The sequence of events when traversing the parse tree is the following. On startElement, see if the top node in the stack knows how to deal with its own children, [it does] then pass the element type, attributes and cdata to the top stack node while still in this node. [it does not] then try to create the appropriate ...
ReportElement: This is the interface that provides the basic facilities of the package. It will provide methods to access and modify properties of individual reporting elements. All modification of element properties should be through methods of this interface. This will then ensure that both API and XML reporting methods are possible. Furthermore, concrete instances of this interface should be created through the use of the appropriate ReportElementFactory instance. This is also required to ensure both types of reporting methods are possible. The rendering packages will use the properties made available through ...
ReportVisitorState: This is used to define the state of a traversal to the Visitor of a class. We provide this, as various types of callbacks will be made available that might result in the same instance being visited more than once. This is required in order to cater for visitors that generate markup which consists of begin and end tags. It can also be used to generate display trees, the depth of which is obtained in a more efficient manner than would otherwise be possible. We also make it possible for user state to be moved around during the the traversal by means of the getUserData() and setUserData() methods.
RepositoryImpl: This represents a storage area for a bunch of other element types, including but not limited to, datasources, queries, documents, etc. As many repositories are allowed, this class provides methods to search for repositories. It should be noted that a repository forms its' own namespace, and that elements such as queries can be obtained by referring to a given namespace. ie. should a Query x be required from Repository y, we can either get Repository y, and then call getQuery("x") on it, or if we already have a Repository z, then the call getQuery("y.x") will return the same Query element.
Datasource: This represents a source of data. It is used in association with the Query class to obtain data which is then used in rendering the report. Internally, this uses the State (GOF p305) pattern, where the state is the type of datasource that is created. When an instance of this class is created, there is no useable state, and the application should set the type of datasource, and any properties that are applicable. This is then used to create the correct physical datasource connection. There are two currently available datasource types, namely, JDBC and class factory (java).
Stack: This provides for the semantics of a stack. By default it uses a java.util.ArrayList for management, but this can be changed by passing the appropriate java.util.List instance to the alternate constructor. This is otherwise known as a FILO (First in, last out) list. The existing stack from the java.util.* package was not used, as it is extended from the Vector class, which is fully synchronized. This is not a behaviour that is needed by default. IMHO. We do provide for all of the methods in the java.util.Stack class tho'.
Repository: This represents a storage area for a bunch of other element types, including but not limited to, datasources, queries, documents, etc. It should be noted that a repository forms its' own namespace, and that elements such as queries can be obtained by referring to a given namespace. ie. should a Query x be required from Repository y, we can either get Repository y, and then call getQuery("x") on it, or if we already have a Repository z, then the call getQuery("y.x") will return the same Query element.
ReportVisitor: Define the operations that are available to iterators walking a ReportElement hierarchy. These methods will be called by the ReportElements themselves, when their accept methods are called. All methods are defined as taking a ReportElement instance. Access to properties of the concrete instance should be done through the appropriate accessors on the ReportElement interface. Under no circumstances should the concrete ReportElement instance be cast to a concrete type.
MemoryTrack: This will create a thread that will monitor the state of the memory usage of this application. It is envisioned that this will eventually be tied to both the naming and messaging services. This class is made into a singleton, as we can only track memory for the entire VM, so making it any more fine-grained would be pointless. We should track trends in the memory, such as memory delta per time both over short, and longer periods of time.
BasicReportServlet: This is the controller instance for basic reporting functions. It will redirect as appropriate to named jsp's for further information capture. At the moment, we don't cater for application connection instances, but will do so in the future. All the initialization parameters for this servlet will be read in from the properties file in this package.
Group: This provides a home for both queries and break elements. All ReportSection elements should be enclosed by a group, should they require either data handling or breaks. The alternative to this would be some form of on-the-fly normalization. This route was considered and discounted as the author felt this would be difficult to debug and maintain.
ReportElementFactoryImpl: This is the default implementation of the ReportElementFactory interface. It reads the appropropriate element mapping in from the parse.properties file, and then uses that to map the element types into java classes. This is still quite a simple file, as none of the element identifiers are used in more than one context.
DefaultReportVisitor: This is an implementation of the ReportVisitor interface which does nothing. It is provided as a convenience to aid writing concrete implementations of the ReportVisitor class. For more advanced uses, this class implements the Composite pattern, and enables more than one ReportVisitor to be used for every traversal.
Traversable: Defines an interface which allows classes to traverse the hierarchy of elements in a predefined fashion. At each point in the traversal, this enables a callback to a well-defined method. We use the Iterator [GOF 257] pattern to perform the iteration and the Visitor [GOF 331] pattern to perform the operation.
BreakEventListener: This interface defines the methods that should be implemented by any class that needs to be notified of break events during the loadData phase of report creation. This enables classes to do any splitting of pages, printing of headers, etc. that might be required during the report generation.
XMLAware: This interface defines the operations that will be performed on an element that implements this interface during the xml parse tree traversal. It's not really necessary at the moment, but I don't want any public methods in AbstractReportElement that are not defined by some interface.
ReportBreak: A ReportBreak element is defined such that it can be tested to see if a condition has been met which defines a break in the report. The definition of this interface dictates that a concrete instance can only be responsible for a single condition.
ConnectionFactory: This is used to fetch a connection instance from the application. This enables re-use of application level connections, with all of the appropriate security checks in place. For valid use, it should have a public no-args constructor.
ReportFacade: Defines a facade into the reporting package, hopefully making simple reports easier to define. The system property reportElementFactory is used to setup the factory class that should be used to create report elements.
PhysicalConnection: This interface defines the contract that is required for the class to be pluggable into a Datasource instance. Any classes implementing this method should have a public no-args constructor which can be used by the datasource.
SQLCreate: This will create large sets of sql statements which can then be fed into a database. This data will then be used in the tests. We don't use JDBC to input the data into the database, as that is too much like hard work ;-)
Aggregate: This performs operations on groups of data in the report, all of which are strongly typed. It provides an extensible interface whereby operations can be defined for Aggregates to perform.
XMLOutputReportVisitor: This should be capable of outputting the full xml definition of the report structure. At the moment it caters for the names of the elements, and their identifiers if present.
Include: This will render the named elements that are referenced. This is used to include standard sections of raw output data without cluttering the essential document declaration.