View Poll Results: If you read it, did you find DirectJNgine User's Guide adequate?

54. You may not vote on this poll
  • Yes

    40 74.07%
  • No

    14 25.93%
Page 1 of 50 12311 ... LastLast
Results 1 to 10 of 500

Thread: Ext Direct Java based implementation

  1. #1
    Ext JS Premium Member
    Join Date
    May 2009
    Barcelona (Spain)

    Lightbulb Ext Direct Java based implementation

    We have finished the first public release of DirectJNgine, an Ext Direct implementation for Java.

    You can find the project at

    As far as we know, DirectJNgine is fairly feature complete. For example, it runs all examples provided by ExtJs in examples/direct, as well as our own additional examples and a host of automated tests.

    But, of course, we have to wait for feedback from the community to make sure that it fits the community needs, and that it implements the mandatory Ext Direct feature set.

    Main features

    - Supports all types of request: JSON requests, batched JSON requests, form posts, form posts with file uploads and even polling provider based requests.
    - Fully tested: more than 75 fully automated tests as of version 0.7.1 (beta).
    - Provides a detailed User's Guide (more than 20 pages).
    - Runs all of ExtJs examples in examples/direct.
    - Provides additional examples.
    - A WAR is enclosed showing all examples and running all automated tests.

    For a complete feature list, go to

    How it works -in 30 seconds

    If you are curious about how it works, there is a short excerpt from the User's Guide:
    Now, how is everyday life with DirectJNgine?
    Lets assume that you want your Javascript code to call a sayHello Java method, which will receive a person name and return a greeting message. That is as easy as writing the following Java code:

    public class Action1 {
      public String sayHello( String name) {
        return Hello,  + name + . Nice to meet you!;
    Basically, you write your Java code without much concern for whether it will be called by some Javascript code living in a remote server or not. The secret? Using the @DirectMethod annotation DirectJNgine...
    Of course, there are things to configure, best practices to follow, etc. But adding a new method will just feel like this.
    For further detail, read the User's Guide, please.

    What will be there in version 1.0?

    For the 1.0 release we will provide all that's there in the 0.7.1, and then we plan to:

    - Add support for custom data conversion from Javascript to JSON to Java and back.
    - Enhance the documentation a bit.
    - Increment the number of automated tests well beyond one hundred.
    - Fix small issues.

    We are especially interested in finding all missing pieces there might be with respect to the mandatory feature set.

    And, of course, we are open to feedback and criticism, and will consider other features for which there is a strong demand from the community.

    Beyond 1.0...

    We would love to add better exception reporting...

    We might have to optimize logging: we do some heavy duty logging when logging level is set to DEBUG or TRACE, a must when you are dealing with remote communications and data conversion from Javascript to JSON to Java and back.

    We would like a "safe client call" mode: just try calling MyAction.myMethod( 1, undefined, 2), and you will probably be in for a surprise.
    Or try returning Long.MAX_VALUE from a Java method, and check what number Javascript receives. Avoiding dangerous calls or at least emitting warnings would be nice...

    It would be nice to handle individual requests in batched requests in separate threads, now that we have those nice multicore CPUs...

    And there is the polymorphism issue, when passing objects from Java to JS and then back to Java...

    That said, this is just food for thought, and we having committed yet to post-1.0 features.

    Feedback and criticism

    We are releasing this library in the hope that it is useful to the programming community.
    We understand that this is the first public beta release of the library, which has been tested in a very restricted environment. Unfortunately, that can only guarantee that there is not way for it to be fully feature complete or bug free.

    We are committed to making DirectJNgine a useful library. Therefore, it is only natural that we will be happy to receive feedback and criticism.

    Last, but not least, we hope you enjoy using DirectJNgine as much as we did developing it.



  2. #2
    Sencha User aconran's Avatar
    Join Date
    Mar 2007


    Pedro -

    This looks great! I will add your implementation to the master list of Ext.Direct Server-side stacks.

    Aaron Conran

  3. #3


    This is great !!

    I've tested with extsjs examples, and it works fine.

    We will use it for our project and be sure you'll get feedback if we find bugs.

    Very nice !

  4. #4
    Sencha User Condor's Avatar
    Join Date
    Mar 2007
    The Netherlands


    Any chance of adding support for Apache Commons Attributes to DirectJNgine for people still working on Java 1.4?

  5. #5
    Ext JS Premium Member
    Join Date
    May 2009
    Barcelona (Spain)


    Oops. Yes, those using JDKs older than 1.5 are stuck.
    We need to address this issue.

    I don't like much adding preprocessing steps to compilation, and I think that will be a must with the Apache Commons Attributes library -haven't used it though, maybe there are alternatives...

    Anyway, DirectJNgine annotations are really simple, and we can do without their parameters 99% of the time. I don't think I will add complex annotations later. No need for a full fledged substitute for 1.5 annotations.

    So, what about using a naming convention instead?

    - Methods starting with "djn_" will be considered as annotated with @DirectMethod
    For "djn_xyz" the method name will be "xyz."

    - Those starting with "djnform_" will be considered as a form post method (@DirectPostMethod).
    For "djnform_xyz" the method name will be "xyz."

    - Those starting with "djnpoll_" will be considered as @DirectPollMethod.
    For "djnpoll_xyz", the event name will be "xyz".

    This solution is simple, easy to understand and easy to implement. I think this solves the issue.

    If it is acceptable to everybody, I will consider it for inclusion in the next public release (0.7.3, due on Wednesday 15).

    What do you think?


    Pedro Agullo

  6. #6


    When I tried the supplied war file, it worked perfectly well with firefox3.5, but failed with javascript errors on IE7.

    I thought the user guide was very well written, although still a little incomplete.

    I'm looking forward to the next release.


    Edit: found the problem for IE - too many commas in your javascript!
    Remove the commas in DirectStoreDemo.js at lines 36, 42 and 59 and
    FormPostDemo.js lines 67 and 80.
    Last edited by asgillett; 6 Jul 2009 at 5:12 PM. Reason: found solution

  7. #7
    Ext JS Premium Member
    Join Date
    May 2009
    Barcelona (Spain)


    Thanks for the encouraging words.

    I will fix the IE issues for the next version, due out tomorrow.

    For the final version I plan to add a step to the release procedure for running the automated tests against all major browsers.

  8. #8


    A little error in doc :

    Page 13 :

    In this case, we have to pass the forms el element as the first and only parameter to a server 
    method annotated with @DirectFormMethod, which is implemented as follow
    @DirectPostMethod ?

  9. #9
    Ext JS Premium Member
    Join Date
    May 2009
    Barcelona (Spain)


    Fixed! Thanks.

  10. #10


    I tried to modify a little FormPostDemo.js and the Java to do something like that :

    var remotingProvider = Ext.Direct.addProvider(;
    var form = new Ext.form.FormPanel({
        // url:,
    load: FormPostDemo.load, // Something to load, work perfectly submit: FormPostDemo.submit // here is the problem }, ..... Config / Items / etc...... buttons: [{ text: 'Submit', handler:function(){ form.getForm().submit(); // here is the problem }
    My Java method :
      public Result submit(Map<String, String> formParameters, Map<String, FileItem> fileFields ) throws IOException  {
        for( String fieldName : formParameters.keySet()) {
            System.out.println( fieldName + "</b>='" + formParameters.get(fieldName) + "'<br>");
          return null;
    When i do this, RemoteCallSupport throws an exception, i have 3 parameters wheras the method len is 1.

    If i delete the verification on remotingProvider, it works.

    Is it a bug?

    It would be nice to do things like that to have generic formpanels and just configure them.


Page 1 of 50 12311 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts