SANDev 1.0.0 has been released. This is the first production release.

SANDev is an open source build environment for applications written using Structs and Nodes Development (SAND), a form of message-oriented modeling and development that declares application data (structs) and application processing components (nodes) as java classes supplemented with custom javadoc tags. SANDev provides:

• A dependency-tracking modular 2-stage build (code generation followed by the standard compile/package/doc).
• A deployment configuration tool, allowing definition of global settings, bootstrap data, application module communications, and node params.
• A user interface definition editing tool, allowing definition of screens, forms, links, actions, and values.
• Default templates for web interface look and feel which can be easily customized or replaced.

New features for this release include:

• Support for hot deploy
• New project setup script
• Improved documentation on how to get started

We welcome your feedback and participation. For more information, see the project homepage at http://sandev.org.

I looked through your site and post, but I was unable to see what problem you are trying to fix.

Could you give a brief re-cap of the product and think in terms of how SANDDev would help me in my day to day work as a Java developer ?

Regards

Ian
Script Hosting | Ipod loading

Structs and Nodes Development (SAND) is a paradigm for application design, and SANDev provides tools to do the grunt work. It uses conventions and code generation to facilitate very rapid development cycles for web-based applications. You define a data model (the structs), a series of processing nodes, and the relationships between the nodes. Then you go to work coding the meat of your app (the functionality of the processing nodes) - SAND handles the plumbing.

Why do I like it?
Changing the data model of a 500,000-line enterprise application can be done in 10 minutes using SAND (been there, done that). You don't have to update the EJBs, the authentication/authorization code, the database configuration, the serialization code, the form validation code, the UI code, etc. to handle the new field you just added. The generators do all of that work for you. It's great for adapting to changing customer requirements.

Although it can be shoehorned into existing systems (especially if they're already message-based), SAND really shines when building new applications. You can have a skeleton application running in just a few minutes, and making changes is easy thanks to the generators.

Developing with SAND is a bit different, but I've found the increase in productivity borders on the ridiculous.

Hm, this seems very similar in intent to the Rails framework, isn't it? The intent being, presumably, to automate the most repetitive tasks and focus on the business logic.

That's what I got out of reading the documentation (and not from actually using it, which I haven't yet).

Our intent is to automate significantly more. Rails works from the database model to generate a runtime object model and UI forms. SAND works from a struct definition to generate a database model, object model, UI forms, and a messaging model. SAND also generates the processing components, which are linked to the authorized messaging model. It's more than just data automation, and probably closer in spirit to distributed
systems development.