Compellingly Beautiful Software
Products Programming Contact
At brising.com, we want to help you use your time well. We don't want you to spend hours reading about a product, trying to sift through some vague marketing pitch, only to discover that it's not the right product for you. So let's talk about tasks for which Slamdunk is especially well suited, and eliminate tasks for which some other tool or paradigm will serve you better.
Or skip ahead to learn what you need to know next.
Slamdunk builds real Java UIs, not Javascript.
Slamdunk UIs are easier to develop than equivalent Java code.
Slamdunk builds fully-functional UIs, not just component layouts.
Slamdunk application structure can be standalone or any of the client/server architectures.
Slamdunk UIs run either as applications or as web-based applets without change.
Slamdunk runs on current JRE/JDKs.
Slamdunk easily incorporates your custom Java components.
Slamdunk excels at forms-oriented middleweight-to-heavyweight UIs, and the underlying architecture adapts well to some applications that animate their domain models.
If your database structure or application functionality changes often, or if you have variant data structures, Slamdunk is probably your best choice, because its UIs largely assemble themselves to match the objects they're asked to display. Users of object databases will find this particularly appealing.
If your application accesses databases you do not control for anything other than simple inspection, Slamdunk might be your only reasonable choice, because it automatically integrates UI fragments from other developers. Deep supply chain integration is an example of this, and a lack of something like Slamdunk is a big reason it is rarely attempted.
If your users speak many different languages and expect to see localized UIs, Slamdunk will be very helpful to you, especially if they need to change locales while the application is running.
Developers often wish they had special test UIs to aid in their work. With Slamdunk, you can afford to build them.
The Slamdunk design pattern originated in an industrial control application implemented in the Smalltalk programming language. The founder of brising.com refined and extended it, borrowing some ideas from the Lisp programming language, eventually implementing it in Java. The current implementation is Slamdunk Version 4. There is a lot of history behind this body of code.
The design pattern proposes a set of visible and invisible UI objects, and then places some restrictions on how they may be used. Like the rules of Structured Programming, these restrictions initially appear harsh, but experience quickly shows that this is not the case. In fact, they bring immediate order to an otherwise confused landscape, and make possible some very desirable things that were previously just wishful fantasies. Self-assembling user interfaces is one of them. Tractable UI development schedules is another. What JavaBeans® try to do, Slamdunk actually does, and more simply.
Java is a very popular language, but describing UIs in Java is hard, even with the help of sophisticated drag-and-drop code generators. There are other ways of describing a UI, and there are several other tools/frameworks that do this, most employing XML as their description medium. This can be made to work, but XML has its roots in a document markup language, and thinking of an interactive form as a document is not a good analogy compared to certain others. Because very high developer productivity is one of its goals, Slamdunk uses another notation that is more effective for this task, and far easier to manipulate with automated tools.
Most UI development tools focus on the layout of widgets on a screen. Slamdunk focuses on the underlying structure of a UI. Instead of laying out components and then jumping the gap to the domain model, Slamdunk begins at the model and extrudes the UI incrementally, much like the growth of a tree. The visible UI is almost a side effect. Correct results appear much more quickly, and are more easily maintained. Furthermore, this makes it possible to describe abstract UIs that automatically complete themselves at runtime.
A framework like Slamdunk has to make generalizations about what a UI is and how it works. In the very few cases where these generalizations are found not to apply, and in cases where unusual screen components are needed, developers can integrate their custom components into Slamdunk by following a simple coding recipe. All Slamdunk-compatible objects have the same API, which is exposed and documented for you to use.Slamdunk development begins with your domain models, coded according to a convention you probably already use. UIs for individual domain classes are described, instantiated, and tested right now without compilation or strange modes. Completed descriptions are added to a repository and invoked on demand. These descriptions tend to be small, often 20 to 100 times smaller than the corresponding Java code, with most taking only a few minutes to develop. The resulting UI fragments assemble themselves into larger UI structures without further programmer intervention.
Deployment involves distributing the Slamdunk class library to your users, along with your application-specific code. This library contains about 250 classes, and is not considered large by current standards. If you are deploying applets, there is a Slamdunk server component.
Slamdunk is a product-and-services combination. Along with the class library, tools, and documentation, brising.com assists you with training and consulting. We want to see your application designed, developed, and deployed every bit as fast as you do.
Ready to learn more?
© 2004 brising.com