Ext Direct Java based implementation

**pagullo** · 30 Jul 2009 1:01 AM

The paramsAsHash: true option is not supported, because I felt it will force us to receive values of unknown types, and I was concerned we might end up writing Java code that receives Object parameters all around (unknow type=> need to use Object as parameter type=> we loose Java's type safety) .

Type safety is one of the reasons for using Java at the server side, else why not using a more dynamic server side language?

Therefore, I'm trying to do writing that kind of code difficult -but not impossible.

That said, can you please provide a pair of concrete use cases in which paramsAsHash:true is needed? Will be glad to re-check my assumptions.

And, can you write here your client side call to 'load'?

I feel it is possible to get a great degree of flexibility without having to use the paramsAsHash: true thing.

Regards,

Pedro

**mct** · 30 Jul 2009 2:17 AM

Hi Pedro,
As we already started using DirectJNgine in our project (an open source ERP), and as you propounded the July, 22 for the final 1.0 release, can you tell us please something about the release date of the final DirectJNgine 1.0.
Never mind the date, just to know for planing.
Thank you very much.

**pagullo** · 30 Jul 2009 7:33 AM

We are releasing DirectJNgine 1.0 final today!

Though we had planned to release it in July 22, we decided to add some features that were planned for 1.1 to 1.0, moving a bit the release date: client-side parameter checking and direct JSON handling.

We hope they will be worth the one week delay!

To get DirectJNgine, go to http://code.google.com/p/directjngine/

New: added support for handling JSON directly

From the User's Guide:

We have made every effort to handle serialization from JSON to Java, so that you can write methods that receive good old Java data types. However, there can be cases when you might need to access the JSON data directly for maximum flexibility...

Now, you can do that by making a method annotated with @DirectMethod receive as its only parameter a JsonArray parameter, and DirectJNgine will pass your method the Json data, without making any attempt to decode it.

New: client-side parameter checking (debug only)

We provide many client-side parameter checks. This is optional, and intended to be used in debug mode only.

Take a look at the User's Guide chapter on parameter checking for further info.

Improved: the User's Guide has grown to more than 40 pages.

We have added several new chapters:

- 4. Configuring a new project to use DirectJNgine.
- 9. Servlet configuration parameters.
- 11. Handling JSON data directly.
- 12. Checking client-side calls.

The chapter dedicated to form handling has been rewritten and enhanced to use the form 'api' configuration parameter.

New: additional servlet initialization parameters
- actionsNamespace: This allows us to provide a namespace for Direct actions.
- minify: this allows us to disable api file minification.

Take a look at the User's Guide for an explanation

Improved: fixes and minor enhancements
- Addressed issue with internationalization.
- Improved build.xml

...

Code breaking changes
The 'namespace' servlet intialization parameter has been renamed to 'apiNamespace'. In DirectJNgine 1.0 we have two "namespaces" now, one for apis and another one for actions, and we felt 'namespace' was misleading.

For further info, take a look at the User's Guide documentation on both 'apiNamespace' and 'actionsNamespace'.

...

Note on JDK 1.4 support
We have decided not to support JDK 1.4.

Unfortunately, we use many 1.5 features, especially generics.

Besides, we rely on several libraries that are 1.5 specific, such as Gson. We are very happy with Gson's performance and flexibility, and we feel it would be an important loss for DirectJNgine users not to use it for JSON handling.

...

If you want to take a look at the main DirectJNgine features, I recommend you take some time to read prior postings related to beta and RC versions in this thread, or just take a look at the "Features" chapter in the User's Guide.

...

Regards,

Pedro agulló

**J@y** · 30 Jul 2009 7:49 AM

So great to hear this news!

cheers!

**mediacept** · 30 Jul 2009 10:08 AM

Thank you for the final 1.0 version. Now we can continue to use DirectJNgine and looking ahead.

Thank you to this feature that resolves an OpenJDK bug in Ubuntu (from the user guide, page 37):

By the way, it is highly unlikely that minification fails: we use the YUI ompressor, a very well tested minifier. However, if the YUI Compressor raises some exception or reports some error, we make sure that the minified file will contain at least standard code, so that your application does not break because there is no “-min.js” file.

Good continuation.

**dweller** · 30 Jul 2009 10:38 PM

Originally Posted by pagullo

The paramsAsHash: true option is not supported, because I felt it will force us to receive values of unknown types, and I was concerned we might end up writing Java code that receives Object parameters all around (unknow type=> need to use Object as parameter type=> we loose Java's type safety) .

Type safety is one of the reasons for using Java at the server side, else why not using a more dynamic server side language?

Therefore, I'm trying to do writing that kind of code difficult -but not impossible.

That said, can you please provide a pair of concrete use cases in which paramsAsHash:true is needed? Will be glad to re-check my assumptions.

And, can you write here your client side call to 'load'?

I feel it is possible to get a great degree of flexibility without having to use the paramsAsHash: true thing.

Regards,

Pedro

eg.
Query data by different condition,and parameters number maybe one or more.
yes,we can handle this in clide-side code,but it's better to handle in server-side code.

permitted receive dynamic parameters in server-side code,there will be more flexibility.

**Georgioa** · 31 Jul 2009 1:14 AM

This is nice !!

Thanks !

**mct** · 31 Jul 2009 2:48 AM

Hi,
I have a question for the ExtJS team:

Allowing that the DirectJNgine is in the final and stable release, can you add please in the Ext.Direct Pack (on ExtJS download page) a java folder with DirectJNgine (as cfml, DotNet, php and ruby) ?

Thank you for your response.

**pagullo** · 2 Aug 2009 10:13 PM

Originally Posted by dweller

eg.
Query data by different condition,and parameters number maybe one or more.
yes,we can handle this in clide-side code,but it's better to handle in server-side code.

permitted receive dynamic parameters in server-side code,there will be more flexibility.

I think that you will probably want to give a try to direct JSON handling: take a look at chapter 11 in the User's Guide.

**Georgioa** · 3 Aug 2009 7:44 AM

Hi

I lost lot of time on my DirectStore this afternoon, but i dont known if it is a bug.

So i have my store which call my method. This is ok.

My remote method is :

Code:

    
@DirectMethod
    public Status getLastStatus(){
        return StatusList.getLast();
    }

and returns an objet like this :

Code:

    protected class Status{
        
        private String message;
        private Date time;
        private int avancement;
......

}

So server response is :

Code:

{"result":{"message":"test2","time":"3 aoÃ»t 2009 17:37:24","avancement":6},
  "tid":2,"action":"ThreadStatus","method":"getLastStatus","type":"rpc"}

but my direct store needs something like :

Code:

{"result":[{"message":"test2","time":"3 aoÃ»t 2009 17:37:24","avancement":6}],
  "tid":2,"action":"ThreadStatus","method":"getLastStatus","type":"rpc"}

If my method return a List<Status>, it is ok, but do we need to "encapsulate" objects to send them to the store?

By the way, this happens when a method returns only one object, and not a list of object.....

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

Ext Direct Java based implementation

Thread Tools

Search Thread

Display

Ext.Direct Pack

Ext.Direct Pack