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.

[SreevaniN]

Hi Pedro,

I am planning to use the directjngine stack to help my project which involves calling crossdomain URLs. I must admit that I am still a beginner.

My hello message in my javascript file is coming up, which says that my EXtjs is configured properly.

I have followed the userguide to create a new web app. Now I have created my own class just like you have given and run my application. The Api.js is not getting created automatically. It does not seem to recognize my class!

I will be obliged with any help.

Thanks,
Sreevani

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

[dreamtaotao]

I like DirectJNgine. I tried to DirectJNgine with struts2 integration but it seems impossible, it seems not work with MVC frameworks is that right? For example struts2. If you can do to give some clarification. Thank you, sorry my English not good

[pagullo]

DirectJNgine is only integrated with the servlet API at this moment.

The layer on top of the engine that supports the servlet API is thin, and it should be possible to integrate it with other frameworks/libraries, but at this moment I know of no one who has attempted to integrate DirectJNgine with Struts 2.

That said, I think you can install the DJN servlet and make it coexist with Struts 2, but whether this is applicable will depend on how you plan to use DJN. Deep integration might require extra work, but just using it to handle some chores should be possible.

[Whatty]

Good morning,

We have been working with the djn-spring-1.1-rc1 library and have made a bunch of updates to the Spring Integration adding support for sessions.

I have attached the source code and configuration files required for this to work.

Basically it attempts to locate the Spring bean in the session first and if found uses that instance for invocation of the method, otherwise it asks Spring for the appropriately named bean.

This is a very very rough first attempt at it and believe me there are many many opportunities for refactoring and improving this code but I wanted to get it out there for others to take a look at, possibly use and suggest improvements.

Whatty