Bonus Material

For my customer's project I created a small addition to Sculptor, that might be useful for you also. The domain model is important for communication, and we need to document it. The difficult thing with documentation is to keep it up to date with changes. Placing the descriptions close to the code makes it easier to do the changes to the documentation at the same time as when you change the code. Since we use Sculptor it was a natural choice to write the descriptions in the model file and generated the documentation.

     "A location is our model is stops on a journey, such as cargo
     origin or destination, or carrier movement endpoints."
     Entity Location {
         not optimisticLocking
         - @UnLocode unLocode key
         'Actual name of this location, e.g. "Stockholm"'
         String name not changeable
      
         Repository LocationRepository {
             @Location find(@UnLocode unLocode) throws LocationNotFoundException;
             findAll;
             protected findByKeys;
         }
     }

From the model we generate HTML documentation of all domain objects including their attributes and associations.

Try it if you like. It is easy to understand and adjust to fit your needs.

Download this generation template and place it in src/main/resources/templates/
In SpecialCases.xpt you add

«AROUND templates::Root::Root FOR Application»
   «targetDef.proceed()»
   «EXPAND DomainModelDoc::start»
«ENDAROUND»

The generated result is located in src/generated/resources/DomainModelDoc.html

Sculptor 1.8.0 Released

Only two weeks after the big 1.7.0 we are happy to deliver another major release - 1.8.0. This time it is no new functionality, but the usability of DSL editor is much, much better.

We have migrated from openArchitectureWare 4.3.1 to Xtext/Xpand/MWE 0.7.2 at Eclipse.org. Many thanks to Todd Ferrell for doing most of this migration.

Now, content assist (ctrl+space) works as you would expect.

Another useful feature is formatting (pretty printing) of model files (ctrl+shift+F).

Watch the DSL editor in action in the demo below, or even better try it yourself.

Customization of webflows

With the new 1.7 release of sculptor the possibilities to customize flows for the web client is much better.
With our Library example here is what you can do.
For example, lets say you want to implement filter functionality for the library list feature. Here is the steps to do that:

1) Specify that you want gap-files for the list library feature, so in your model.guidesign:

gui Library for Library {
Module for media {
    ListTask for Library {
        gap
    }
}
}

Now you have a bunch of files for the feature:

• src/generated/java/org...library/ListLibraryActionBase.java
• src/main/java/org...library/ListLibraryAction.java -> gap
• src/generated/java/org...library/ListLibraryForm.java
• src/WEB-INF/generated/flows/media/listLibrary/listLibrary-base.xml
• src/WEB-INF/generated/flows/media/listLibrary/list_include.xhtml
• src/WEB-INF/flows/media/listLibrary/listLibrary-flow.xml -> gap
• src/WEB-INF/flows/media/listLibrary/list.xhtml -> gap

2) Edit the media/listLibrary flow:

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
     xmlns:ns0="http://www.w3.org/2001/XMLSchema-instance"
     ns0:schemaLocation="http://www.springframework.org/schema/webflow
     http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd"
     parent="media/listLibraryBase">
 <view-state id="list">
     <transition on="filterLibrary" to="listByFilter" />
 </view-state>
 <view-state id="listByFilter" model="listLibraryForm"
     view="/WEB-INF/flows/media/listLibrary/list.xhtml" parent="media/listLibraryBase#list">
     <on-render>
         <evaluate
             expression="listLibraryAction.findByFilter(flowRequestContext)" />
     </on-render>
 </view-state>
</flow>

3) Edit the ListLibraryAction, add the method:

public String findByFilter(RequestContext ctx) {
    getRepository().clear();

    List<library> allLibraries = getLibraryService().findAll(ServiceContextStore.get());
    List<library> filtered = new ArrayList<library>();
    String filter = ctx.getRequestParameters().get("libraryFilter");
    for (Library library : allLibraries) {
        if (library.getName().startsWith(filter)) {
            filtered.add(library);
        }
    }
    formObject(ctx).setAllLibraries(filtered);
    return "success";
}

4) Add a simple form with a text field and a button to the media/listLibrary/list.xhtml-file:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:f="http://java.sun.com/jsf/core" xmlns:t="http://myfaces.apache.org/tomahawk"
 xmlns:h="http://java.sun.com/jsf/html" xmlns:c="http://java.sun.com/jstl/core"
 xmlns:a="ApplicationTaglib">
 <body>
     <ui:composition template="/WEB-INF/common/template.xhtml">
         <ui:define name="content">
             <h1>
                 <h:outputFormat value="#{msg['list.header']}">
                     <f:param
                         value="#{msgMedia['model.DomainObject.Library.plural']}" />
                 </h:outputFormat>
             </h1>
             <h:form xmlns="http://www.w3.org/1999/xhtml"
                 xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:f="http://java.sun.com/jsf/core"
                 xmlns:t="http://myfaces.apache.org/tomahawk"
                 xmlns:h="http://java.sun.com/jsf/html" xmlns:c="http://java.sun.com/jstl/core"
                 xmlns:a="ApplicationTaglib">
             <div>
                 <label for="_libraryFilter">#{msgMedia['model.DomainObject.Library.filter']}: </label>
                 <input type="text" value="#{requestParameters.libraryFilter}" name="libraryFilter" id="_libraryFilter"/>
                 <h:commandButton value="#{msgMedia['model.DomainObject.Library.filterButton']}" action="filterLibrary" />
             </div>
             </h:form>
             <ui:include
                 src="/WEB-INF/generated/flows/media/listLibrary/list_include.html" />
         </ui:define>
     </ui:composition>
 </body>
</html>

Note that the default generated table showing the list result is used by including the generated file. In case you need to modify the generated content you can either overwrite the code generation templates in WebSpecialCases.xpt or simply copy the generated file and maintain it manually

That's it.

Two Success Stories from Factory4Solutions

Introduction
I work as architect at company Factory4Solutions (www.f4s.sk). Our
primary customers are banks, insurance companies, telecommunication
sector. We was using MDA approach long before. We started around 1997
with our own home made solution based on RationalRose, XML and custom
generator. Than we switched to AndroMDA. Tool was nice but stalled in
development around 2007. Then I start investigate another MDA tools.
We were looking for tool based on open technologies, universal and able
to generate JEE code. After playing little bit with proof of concept
projects we got first real project in which we could apply it.

Insurance company
Decision was not easy. We have to migrate existing portal with huge
amount of existing data to new portal. Persistent layer was hand
written in Oracle TopLink and front-end was in JSPs. I expected many
problems because hand written persistent layer is usually full of
nonstandard approaches which are hard to achieve in generic MDA tool.

However for me as an architect it was important to achieve
standardization because we had complicated deployment mode. Because of
security, portal was split to two. First was 3 tier extranet deployed
on WebLogic cluster and internal part which had similar functionality
but was running only on single server. Both portals were using same
database. For easier development I decided go with only one code base.
At build time we split the application and created more WAR files (Full
intranet, Extranet service tier, Extranet web tier).

I was really afraid about MDA approach. I started with SQL DDL and
created first version of model design file for Sculptor. Then I started
to tweak model file to fit existing database. After 2 days I was ready

with our model and first version of important services.

Thanks to strict Domain Driven Design which Sculptor follow I moved
code to developers to finish services and develop web frontend. Thanks
to Spring Remoting it took just 1 day to develop build procedure for 3
different WAR files. Except some small problems when developer used
some utility methods from frontend on backend. The architecture is stable,
system is maintainable and extendable. Today we still use one code
base also for demo system, batch processing system and Web Service
layer. Flexibility of Sculptor is endless. When you reach the border
with what Sculptor allow, you are still free to override parts of
generated code thanks to Xpand language.

Project facts:

• 6 developers + 0.5 architect + 1 project manager + 0.5 auality assurance + 0.5 analyst for 9 month
• 108.000 lines of java code, 34.000 lines of JSP code
• Processing big reports from customers take 5-6 minutes (10 MB XML)
• 20.000 reports a day are send in peaks

Investment company
We had advantage that we should start from scratch. Now project
consist of 40 entities and 26 services. Very complex security and
entity processing by complicated business processes involving bank,
customers, internal users, stock exchange, e-mail processing and
advisor networks. It was developed fully with Sculptor for entity and
service tier.

This is our first project where we used Sculptor also for generating
web frontend. We used smartclient (Sculptor allow to generate different
frontends). We are satisfied with speed of development and nice GUI
which users appreciate.

We also used very unique concept of waving rule engine - Drools

in front of service tier. This way we validate objects, sending

announcement, sending business alerts and also for complex price

list processing which consist of 8 different payment tables applied

at complex conditions. Result is very robust system which allow at

one side dynamic change but on other side very stable.

We are now running User Acceptance Tests at client side.

Project facts:

• 2 developers + 0.5 architect + 0.5 quality assurance during 6 month
• 9.000 lines of hand written code, 3.600 lines of test code, 49.000 lines of generated code

Conclusion
Today we are using Sculptor for all our projects. We master it to nice
extend and we now participate in development of new versions. I'm very
happy with new 1.7 release. This brings some nice features.
Specifically it's Smartclient frontend, hints for custom generation of
code and condition criteria builder with nice Java DSL (type and name
checking and IDE autocompletion).

This story was written by Pavel Tavoda, Factory4Solutions

An Old Success Story

It was a completely new project started from scratch. The main goal of a project was processing of a big files and then generates reports. Despite the fact that installation of a product includes configuration for personal and network use, we choose choose architecture of app that includes Tomcat and Hibernate. After some investigation I found Sculptor. It uses well known (by me) technologies and best practices for that moment. When main functionality was implemented in a draft state Sculptor helped to start with a simple domain model. It was not really big model. This model includes about 50 entities and services (Users, Reports, Settings, Schedule, Directory objects, ...). It was implemented by a team with a different experience in JEE technologies. And almost all of them started to use Sculptor model very quickly.

Our team used SCRUM as a development process. So, it was really exciting "Agile" process implementation. Even Domain Model was agile! There were several serious refactorings that includes changes in Domain Model and Sculptor framework supported this in several ways. First, It requires tests implementation, so our changes was tested just after applying. Second, the way Sculptor uses to separate generated and hand-written code doesn't prevent refactorings. Sure, there were some minor problems, e.g. with using "lazy" initialization. But they were successfully solved and now product is on the market.

Regards,

Vladimir

December 2008

Sculptor 1.7.0 - GAE, Smartclient, EclipseLink, DataNucleus, JEE

Sculptor 1.7.0 has been released. In this version the list of supported technologies has grown with several popular alternatives.

Sculptor has many built in customization options to pick and choose from. The major new target implementation options in this release:

• Google App Engine
• EclipseLink and DataNucleus JPA Provider
• Smartclient GWT
• Pure EJB3 (without Spring)
• Web Services with JAX-WS

Sculptor also has good possibilities for extensibility if you prefer a design or framework that is not supported out-of-the-box. Sculptor is using openArchitectureWare code generation platform, which makes it possible to change the code generation templates using Aspect-Oriented Programming (AOP) features.

The Pure EJB3 implementation, one of the new features in 1.7.0, has already been successfully used in several projects, i.e. it is well tested and production ready. This means that not only Spring users can gain the productivity and quality benefits of Sculptor, but also those who develop on the standard JEE stack.