non-core defines the set of packages where new classes would be created in the course of writing an application:
Once the application-domain has been reasonably understood this knowledge can be used to code new classes under the data and store packages. For the new screens the activity would be under view. The actual controller code could then go under applic. All of these four places have sub-packages that are named by application, so development is a matter of following on from previous applications.
Ignore ubiquitous packages
We will start with the packages that are dependency end points, in that they are only depended upon by other packages. util would normally require no explanation. Here it is not actually a sink, but uses classes in the package note. The package note is actually a sink, and is widely depended upon by other packages. It is where debugging output for each issue can have one central point where it can be described and turned on or off. Everything depends on util so we can put it and bug out of mind from now on.
task package
Tasks are defined as small programs that will never be part of an application, but are useful for one-off jobs that may possibly need to be done again. Many of the tasks currently under the task package are concerned with DO display, population and adjustment. For example, a task to refill a database with known good data would be found here under a sub-package reflecting the application-domain. Useful example applications and investigations into the Strandz code are also found here. Some of these tasks will even be all text and no code - if it ended up that that was what was required to work an issue through.
service package
A service is a daemon that fulfills an important runtime role. The word runtime differentiates it from a task. All the classes in this package happen to be JDO servers, whose job it is to sit atop a JDBC database and fulfill application requests for data.
data package
data contains both business and domain objects (DOs), and is organised by application-domain. Business objects are not persisted while DOs are. Business object classes manipulate DOs that are in turn manipulated by Triggers Files.
widgets package
widgets is the name we have chosen for screen controls/components. Its sub-packages exist to further classify widgets into those that use general DOs (such as Time and Money), and those that use application-domain specific DOs.
view package
The top-level view package does have some of its own used by everyone panels, however most of them are posited in application-name specific sub-packages. And almost to a rule they are panels, meaning they extend JPanel. If you can see it in an application, then it can be found in widgets or view.
Where is the model package?
As this is a Strandz application there is no model package to be found. The model for any application will be encompassed in one or more SdzBags, which will be instantiated in classes under the application package. The structure of each SdzBag will be defined in terms of classes to be found under the core package.
applic package
The control package is called applic, and is where you will find all the application main()s as well as classes of the form application-nameStrand, application-nameTriggers, application-nameEvent and application-nameDT. These classes are at the centre of what any Strandz application does.
store package
store is where the plumbing goes for setting up communication with data. JDO, XMLEncoded and Serialized data stores are currently supported. In the application-domain specific packages you will find lists of the Domain Objects (DOs) and queries that make up the logical database used by the application-domain. These DOs/queries that go to make up a logical database are independent from the actual databases (which are defined by connection properties). There is more on this at the About Strandz/Non-core/Data Stores.
core package
This is the heart of Strandz, and is examined at About Strandz/Core/Packages. Of the sub-packages under here three are imported by the programmer when writing trigger code. These are core.domain (and its sub-packages), core.interf and core.visual.
test package
Lastly there are packages called test throughout the source code structure. This happens to be the highest level one. These packages contain unit test classes.
|
