Skip to content
Ralph Schaer edited this page Dec 7, 2013 · 50 revisions

1.2.3 - November 30, 2012

  • Fix for issue 45. Automatically recognize Calendar as a date type.

  • Fix for issue 46. Remove dependency on RouterController in ModelGenerator. This allows the use of ModelGenerator in a simple servlet:

@WebServlet(urlPatterns = "/app/model/Song.js")
public class SongModelServlet extends HttpServlet {

	@Override
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException,
			IOException {
		ModelGenerator.writeModel(request, response, Song.class, OutputFormat.EXTJS4);
	}

}

1.2.2 - October 31, 2012

  • Configurable provider type. The type can be globally set with the Configuration.providerType property. The default value is 'remoting' and creates a Ext.direct.RemotingProvider in Ext JS. Here an example if somebody created a hypothetical Ext.direct.SampleProvider and want to use that for Ext Direct calls.
<bean id="extDirectSpringConfiguration" 
      class="ch.ralscha.extdirectspring.controller.Configuration" 
      p:providerType="sample"/>

Output of api-debug.js:

Ext.app.REMOTING_API = {
  "url" : "/demo/router",
  "type" : "sample",
  "actions" : {
    ...
    } ]
  }
};
  • Server-Sent Event support. Added a new method type ExtDirectMethod.SSE. This is an alternative to POLL methods. SSE methods are called by the EventSource object from the client side. See more information here: SSE-Method

  • The model generator is now able to generate validation configuration. It tries to read the javax.validation Annotations and adds corresponding validation configurations to the model. See more information here: ModelGenerator

  • Change the data type of total property in ExtDirectStoreReadResult from Integer to Long. A lot of database libraries use long for count queries.

1.2.1 - September 30, 2012

  • Responses of api.js and api-debug.js are now sent with the Content-Type "application/javascript". According to RFC 4329 this is the official type for JavaScript. Earlier version of the library sent "application/x-javascript".
    The content-type is configurable with Configuration.setJsContentType(String jsContentType)
<bean id="extDirectSpringConfiguration" 
      class="ch.ralscha.extdirectspring.controller.Configuration" 
      p:jsContentType="application/x-javascript"/>
  • The library now adds HTTP response headers to force caching on the client if request to api.js is fingerprinted. These headers are: Vary, Expires, ETag and Cache-Control
    This only happens when the URL is fingerprinted like this: http://myserver/.../api-1.0.js
    After the word 'api' a hyphen and after that any character follows.
    Examples: api-a.js, api-1.1.1.js, api-ac12e5f914.js, api-20120808101545.js

  • FORM_POST methods no longer need to be a member of a @Controller class and no longer need the @RequestMapping annotation. They can now be a member of any Spring managed bean (@Service, @Component, ...) like all the other extdirectspring method types. But they have to return an instance of ExtDirectFormPostResult.
    The old way with @Controller, @RequestMapping, return type void and ExtDirectResponseBuilder still works, so there is no need to change old code.
    Example:

//OLD. Still supported
@Controller
public class Profile {
    @ExtDirectMethod(ExtDirectMethodType.FORM_POST)
    @RequestMapping(value = "/updateBasicInfo", method = RequestMethod.POST)
    public void updateBasicInfo(HttpServletRequest request, final HttpServletResponse response, 
                                @Valid final BasicInfo basicInfo, BindingResult result) {
        //....
        ExtDirectResponseBuilder.create(request, response).addErrors(result).buildAndWrite();
    }
}
//NEW
@Service
public class Profile {
    @ExtDirectMethod(value = ExtDirectMethodType.FORM_POST, group = "form")
    public ExtDirectFormPostResult updateBasicInfo(@Valid BasicInfo basicInfo, BindingResult result) {
        //....
        return new ExtDirectFormPostResult(result);
    }
}
  • Renamed ExtDirectStoreResponse to ExtDirectStoreReadResult. Makes it clear that this is not the actual response but is wrapped in an ExtDirectResponse instance (result property) before the framework converts it into a JSON. This way we have a consistent naming scheme.
    ExtDirectFormLoadResult (FORM_LOAD), ExtDirectFormPostResult (FORM_POST), ExtDirectStoreReadResult (STORE_READ)
    And if you look at the JSON the result object corresponds to one of these Result classes.

    ExtDirectStoreResponse is now a subclass of ExtDirectStoreReadResult and is annotated with @Deprecated. This way existing code still compiles and works but reports a deprecated warning.
    Same for ExtDirectRawJsonStoreResult/ExtDirectRawJsonStoreReadResult.

  • Support for concurrent execution of batched method calls. This is disabled by default. To enable it set Configuration.batchedMethodsExecutionPolicy to CONCURRENT and specify a thread pool Configuration.batchedMethodsExecutorService. If the policy is set to CONCURRENT and no executor service is specified the library will create a fixed thread pool with 5 threads (Executors.newFixedThreadPool(5)).
    Example:

	<bean id="threadPool" class="org.springframework.scheduling.concurrent.ThreadPoolExecutorFactoryBean">
	  <property name="corePoolSize" value="50" />
	  <property name="maxPoolSize" value="200" />
	  <property name="queueCapacity" value="5000" />
	</bean>

	<bean id="extDirectSpringConfiguration" class="ch.ralscha.extdirectspring.controller.Configuration">
	    <property name="batchedMethodsExecutionPolicy" value="CONCURRENT" />
	    <property name="batchedMethodsExecutorService" ref="threadPool"/>
	</bean>

1.2.0 - July 31, 2012

  • Bump Jackson to version 2.0

  • New minimal requirements for this release are: Java 1.6, Spring 3.1.2, Jackson 2.0.5 and Servlet 2.4

    If you stuck with Java 1.5 use version 1.1.x. This release is still supported.

Changelog for older version 1.1.x

Clone this wiki locally