Structs and Nodes Development (SAND)

How to use it:

  1. Verify you have Java, Tomcat, PostgreSQL (or MySQL or equivalent), Ant, and preferably CVS installed.
  2. Download SAND.
  3. Build the sample project to test everything is working and get a feel for SAND.
  4. Create your own project.

Prerequisite software:

SAND is built on Java. Although it could theoretically be applied to any language that supports comments, being OO with support for interfaces doesn't hurt, and Java is all that has been done so far. SAND could also be applied to a variety of deployment environments, but currently it targets a web server/relational database environment. SAND requires a two stage build: first the generators update any generated code that needs to be changed, then the standard compilation and packaging. The build is currently implemented using Ant with some custom tasks. To use SAND you will need this prerequisite software.

Java

Download and install the JDK (aka J2SE at the time of this writing). After installing, define the JAVA_HOME environment variable to be the location where Java was installed. The SAND build looks for JAVA_HOME/lib for the .jar files to compile with.

Compatibility notes:

Tomcat

Download and install Tomcat. After installing, define the TOMCAT_HOME environment variable to be the directory where tomcat was installed (e.g. one level up from where the "webapps" directory is).

Turbocharge your installation with the following additional capabilities that SAND needs:

  1. Mail: Download javamail together with the required JavaBeans Activation Framework. Copy mail.jar and activation.jar into tomcat lib.
  2. JMS: If you are using JMS messaging, then add the JMS support files from your vendor into tomcat/lib. Otherwise you can download the JMS API and copy the .jar files into tomcat lib for SAND to use for compilation. JMS is not required at runtime unless you specify using the AuthorizedJMSMessager for your deployment.

Define the J2EE_HOME environment variable to be the location of these additional tomcat files. The build will look in J2EE_HOME/lib for the .jar files it needs.

PostgreSQL (or MySQL or equivalent)

By default, SAND uses JDBC for persistence. If you do not already have a JDBC database installed, download PostgreSQL and install it. Then copy the runtime driver into the tomcat lib area where you put the mail and messaging support jar files.

Using other databases:

Define LOCDB_USERPASS to be postgres,mypassword or whatever you have set up for database access (or edit the build file).

Apache Ant

Download and install Apache Ant. The SAND build needs to be able to find both ant.jar (core tasks) and sandbuild.jar (custom tasks). Easiest thing to do is modify your CLASSPATH environment variable to include these (e.g CLASSPATH=/Developer/Java/Ant/lib/ant.jar:$SAND_HOME/platform/sandbuild/env/sandbuild.jar... More on sandbuild.jar later on.

CVS

If you do not already have a CVS client installed, we recommend pulling down the latest from the CvsGui project and installing that.


Download SAND

To download SAND you can pull down the latest released zip file and unpack it somewhere on your drive for use. However if you want to keep up with the latest fixes and updates we recommend pulling down the latest from our sourceforge CVS server. The modulename to download is "sand" (no quotes). So for example

Then you can just update whenever you want to get the latest. Once you have the source, define the SAND_HOME environment variable to be the sand directory (e.g. /general/sand).


Build the sample project

  1. Verify the sandbuild.jar file with the custom Ant tasks is up to date:

      cd $SAND_HOME/platform/sandbuild/build
      ant

  2. Verify the taskheap database exists:

      /usr/local/bin/psql -d taskheap -U postgres
    If you get an error saying database "taskheap" does not exist, then
      /usr/local/bin/createdb taskheap -U postgres
  3. Build the sample TaskHeapDemo application:

      cd $SAND_HOME/deploy/TaskHeapDemo/build
      ant

    The SANDev build process has the following stages:

    1. Load: The current project and any of the projects it requires are loaded and organized in dependency order.
    2. Code generation: The code generators are run according to their scope (local project, cross project, struct, node, or both).
    3. Standard build: Compile, .jar, .war, javadoc for each project.
    4. Deployment: .war repackaging and copying to local deployment.

    The build trace has details on what code was generated, which gives an idea of how much of the TaskHeap app was written by machine.

  4. Verify the demo app comes up:

    1. open the generated $SAND_HOME/docs/index.html
    2. click the "TaskHeapDemo" link in the upper left
    3. click the "localhost TaskHeap webapp user interface" link in the generated page contents.

    If you want to play with the TaskHeap app, you can login as admin/whatever to start. This account was defined as part of the initial data config which is also accessible from the deployment docs page. There are numerous other doc links for the project useful for development which you can explore for the apps, deployment, and platform tools used for TaskHeapDemo.

The generators in SAND run every time you build, but only write new code if struct or node declarations were actually changed. To clean up everything that was built use ant scrub.


Create your own project:

The script will ask you a few questions and set up your project. Once it has completed, change to the deployment build directory you set up and run ant.

A typical SAND project consists of an application and a deployment. So for a project called MyApp you might have:

each with the following subdirectories and files:


Create your structs

A struct is a plain java class declaration with a name ending in "Struct" which is placed into the structs source directory. So the source file would be something like:

For some working struct declarations see:
TaskStruct.java or PlanComponentStruct.java

A struct contains only protected data member variables and meta tags. The base types for data members can be:

Types can be further refined in generated code using metadata tags. At the class level, a struct declares itself using

By convention the struct level tags are named StructTag*. Use the FieldTag* tags for member data variable declarations. See org.sandev.generator.tags for a complete list of metadata tag descriptions.

A struct may extend another struct.

By default, the AuthFilter will deny all access to messages not explicitely authorized. You will need to edit the AuthFilter implementation (in the UserLookup dir) for appropriate access to each new struct you define.


Create your nodes

A node is a plain java class declaration with a name ending in "NodeDecl" which is placed into its own source package. So the source file would be something like:

For some working node declarations see:
PlanCalculatorNodeDecl.java or TaskHeapUINodeDecl.java

A node may declare configuration parameters using the primitive types int, long, double, String, Date and the associated subset of struct metadata. A node declares all of its communication requirements and supported processing through:

tags. The tags are translated into supporting code in the generated NodeBase source file and used by the business logic in the hand coded Node file. For MyLogicNode, the source file structure is:

The node declaration describes what messages are processed. Where messages are sent to and received from is set in the configuration.


Create your config

The bootstrap data for your application, the server(s) it runs on, and the nodes that make up the runtime architecture are declared using the Configuration Editor which is accessed via a link off the deployment project docsite page. The configuration is saved in the config.xml file in the env directory of the deployment. For an example see deploy/TaskHeapDemo/env/config.xml.

Until the graphical configuration editor is completed, we recommend placing a drawing of your configuration into the intro.html file for your deployment to serve as a reference. For details on the configuration structure, see the description of the struct in the basics project. Also see Messaging.html in the top level docs.


Create your UI

The screens that make up your application, the forms, custom tabs, custom action buttons, and generated output values are declared using the SandUI Editor which is accessed via a link off the deployment project docsite page. The UI definition is saved in the SandUI.xml file in the env directory of the deployment and becomes part of your deployment .war file. For an example see deploy/TaskHeapDemo/env/TaskHeapDemoSandUI.xml.

For details on the SandUI structure, see the description of the struct in the ui project. Also see UIGen.html in the top level docs.


Customize your display

With the SandUI and supporting code defined, the default templates provide enough functionality to enter development data, which completes the raw material for creating a custom UI display. To customize, edit the XSLT templates in the webapp/templates subdirectory of the deployment. Rebuild to redeploy the changes.

During the early stages of UI development, it is sometimes helpful to retrieve the raw XHTML output from your application, save it to a file, and then work applying your template to that file directly rather than rebuilding and redeploying the app for each minor change. To retrieve the unconverted XHTML output from your app, specify the raw=true URL parameter. The base UIActionHandler also allows you to specify the screen, message class, uniqueID and action button name. Some examples:

See the templates in the TaskHeapDemo webapp directory for other useful techniques.





For more information, see sandev.org.