Here we follow-on from About Strandz/Non-core/Packages, where we mentioned that the core package contained three sub-packages that are imported by the programmer when writing trigger code: core.domain (and its sub-packages), core.interf and core.visual. We will get to these after a brief look at some of the others.
info package
The word info is borrowed from BeanInfo. It is in this package that GUI component toolkits are plugged in to Strandz. Here an abstract set of classes can be inherited from in order to describe a toolkit.
The kind of things Strandz needs to know about various widgets are:
-
Are you a table style of widget, or a simple one item widget? (If a table style widget then
TableControlDescriptor is used rather than FieldControlDescriptor).
-
What kind of DO field types do you support? (String is the most common type, but more interesting widgets support other types).
-
What methods should I use to
get and set your values?
-
What method do I use to cause you to be focused?
The vast majority of the code in here is concerned with enabling Strandz to interact with widgets, however other externalities are also described here. For example what colour should be used to indicate an error? Also currently included is other information that helps to describe the Strandz setup to a design-time tool.
info.convert package
The classes in here are called upon when for example you have a widget that takes a String, yet you have associated this widget (using an Attribute) with say a Date. In this case the installation of a DateInTextComponentConvert will insure that the correct reading and writing in and out of the DO field will occur.
info.domain package and info.impl package
info.impl is where the implementations of the abstract classes in info.domain occur. The best way to get a new widget to be recognised by Strandz is to find a similar one and cut and paste the code.
widgets package
Dummy widgets for non-visual Attributes are kept here. If, as advocated at About Strandz/Methodology, you created a completely screenless application, then these dummy widgets would lie behind your attributes, and store the piece/s of data that would otherwise exist in visual controls.
extent package
Strandz recognises data in the form of lists. In this package different types of lists are made utilizable by Strandz. This is a very stable package.
domain package
This package contains quite a few interfaces and is the stable package within core, that is widely depended upon by the rest of core. When you are writing trigger code it is where the triggers, events, exceptions and constants come from.
interf package
interf is named to represent the main interface to classes that will be imported into trigger files. This is where all the SdzBeans are to be found.
visual package
Other Packages
We have not mentioned a few packages here, namely prod, record and relational. prod is basically the core within the core, so there is a deeper level yet! record is for recording and then playing back user-commands. relational contains another type of recorder, which records the SQL commands that would be being performed if every DO was a relational table, basically inserts, updates and deletes.
|
