Ext Direct Java based implementation

[pagullo]

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

You can find the project at http://code.google.com/p/directjngine/.

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 http://code.google.com/p/directjngine/.


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?
Let’s 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 {
@DirectMethod
  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.

Regards,

Pedro

[aconran]

Pedro -

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

Thanks,

[Georgioa]

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 !

[Condor]

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

[pagullo]

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?

Regards,

Pedro Agullo

[asgillett]

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.


Andrew

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.

[pagullo]

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.

[Georgioa]

A little error in doc :

Page 13 :

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

@DirectPostMethod ?

[pagullo]

Fixed! Thanks.

[Georgioa]

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

var remotingProvider = Ext.Direct.addProvider( Ext.app.REMOTING_API);
Djn.RemoteCallSupport.addCallValidation(remotingProvider);

var form = new Ext.form.FormPanel({
    // url: Ext.app.PROVIDER_BASE_URL,
api:{
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 :

  
  @DirectPostMethod
  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.

Regards,
GeorgioA