How to use it:
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.
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:
SAND_HOME/apps/basics/build/generate/org/sandev/generator
create empty class declarations in the
com.sun.javadoc package: 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:
mail.jar and activation.jar into tomcat
lib.
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.
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:
To use a different JDBC database, you will need to change
sandpersist declarations in the build.xml
for the deployment (so if you were building TaskHeapDemo, you
would edit sand/deploy/TaskHeapDemo/build.xml).
Locate the lines that look like
structMapperClass="org.sandev.generator.PostgreSQLStructMapper"
dataSource="direct:org.postgresql.Driver,jdbc:postgresql:taskheap,${LOCDB_USERPASS}"
org.sandev.generator.MySQLStructMapper,
org.sandev.generator.DefaultSQLStructMapper, or your
own custom mapping specification. Change the datasource to be
whatever your database documentation specifies should be used for a
JDBC connection.
To use a non-JDBC database, you will need to change the persisterClass
for the sandpersist declaration to specify a different implementation
of the Persister interface.
Define LOCDB_USERPASS to
be postgres,mypassword or whatever you have set up for
database access (or edit the build file).
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.
If you do not already have a CVS client installed, we recommend pulling down the latest from the CvsGui project and installing that.
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
cvs -z3 -d:pserver:anonymous@sandev.cvs.sourceforge.net:/cvsroot/sandev co -P sand
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).
Verify the sandbuild.jar file with the custom Ant tasks is up to date:
cd $SAND_HOME/platform/sandbuild/build
ant
Verify the taskheap database exists:
/usr/local/bin/psql -d taskheap -U postgres
/usr/local/bin/createdb taskheap -U postgres
Build the sample TaskHeapDemo application:
cd $SAND_HOME/deploy/TaskHeapDemo/build
ant
The SANDev build process has the following stages:
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.
Verify the demo app comes up:
$SAND_HOME/docs/index.html
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.
cd $SAND_HOME/deploy/TaskHeapDemo/build
ant scrub
ant -f initproj.xml
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:
sand/apps/MyApp
sand/deploy/MyAppMain
buildbuild.xml (see the
TaskHeap and
TaskHeapDemo
build files for what this file should look like.
docsintro.html (contains a description of the project)
src (contains the struct and node definitions)
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:
sand/apps/MyApp/src/org/MYDOMAIN/MyApp/structs/MyDataStruct.java
A struct contains only protected data member variables and meta tags. The base types for data members can be:
int, long, double, String, Date
long with reference
metatag)
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.
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:
sand/apps/MyApp/src/org/MYDOMAIN/MyApp/MyLogic/MyLogicNodeDecl.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:
NodeBase source file and used by the business logic in the
hand coded Node file. For MyLogicNode, the
source file structure is: public class MyLogicNodeDecl public class MyLogicNodeBase extends MyLogicNodeDecl //generated filepublic class MyLogicNode extends MyLogicNodeBase
The node declaration describes what messages are processed. Where messages are sent to and received from is set in the configuration.
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.
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.
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:
http://localhost:8080/THD_TaskHeapDemo/TaskHeap?scr=Main&class=Resource&id=1202
http://localhost:8080/THD_TaskHeapDemo/TaskHeap?scr=Main&class=Resource&id=1202&button=edit
http://localhost:8080/THD_TaskHeapDemo/TaskHeap?scr=Main&class=Resource&id=1202&raw=true
See the templates in the TaskHeapDemo webapp directory for other useful techniques.
For more information, see sandev.org.