You have add a lot of feature since a stop releasing the 1.1 version of Djn-spring.. Very good Job.

Actually I'm trying to integrate DJN-1.2 and it's hard to override a lot of method.
For some classes I have to rewrite the full code..
I'm trying to make the less modification without forget that I aim to have a full spring management. I will make a big refactoring in djn-spring to open it to any IOC framework like guice,.. (java7 injection)..

Today I will search different solution but I'm quite sure that I can't do what I want cleanly (without copying your class and add the change I need) with the version 1.2.

So my question is. Have you plan to make a 1.3 version (not for tomorrow )?
May I propose you to change some implementation to open you code or should I do my best with the 1.2 ?

You have add a lot of feature since a stop releasing the 1.1 version of Djn-spring.. Very good Job.

Thanks!

Actually I'm trying to integrate DJN-1.2 and it's hard to override a lot of method.
For some classes I have to rewrite the full code..
I'm trying to make the less modification without forget that I aim to have a full spring management. I will make a big refactoring in djn-spring to open it to any IOC framework like guice,.. (java7 injection)..

Today I will search different solution but I'm quite sure that I can't do what I want cleanly (without copying your class and add the change I need) with the version 1.2.

So my question is. Have you plan to make a 1.3 version (not for tomorrow )?
May I propose you to change some implementation to open you code or should I do my best with the 1.2 ?

Greetings,

I would reallly love to see the DJN-Spring integration solved!

Actually, I have a very early 1.2/1.3+ alpha, with no release date I can commit to. There are no new features, just several small code changes triggered by a detailed analysis of DJN with FindBugs -a nice tool!

I think you should start with that code base: I will post it in googlecode whenever I find some time to clean it up a bit -and with the idea that nobody else uses it.

I would suggest that you contact me once you have finished what you consider the final features you will release, and then we check how/whether to modify DJN to accomodate that. Else, I think we will start running in circles.

Of course, I beg you make the minimal set of changes to DJN so that integration is really feasible with a minimal impact on the core.

BTW: I assume you have checked how I have handled the inclusion of new state management annotations, in the com.softwarementors.extjs.djn.servelet.ssm package.

I think this is a simple way to handle extensibility, as it is independent of the DJN core (if you check it, you will see that DJN can be compiled without the ssm packace, proving that we need not modify the DJN core for some non-trivial cases).

It might need some retouching, but that might the way for you to go. I am really wary of adding more extension points to DJN. They make it more powerful, but they are much harder to test and can deteriore the internal structure: and, one of my main goals is to keep DJN fully tested via automated tests -and we must ensure that remains easy.

Feel free to contact me: just take into account that I am busy, so my answers might take some time!

New Ext Writer Store Example

Would you please add this to the directjngine.1.2 example code? You might find there is an issue. I have tried everything and I can only get my grid to populate. The Add, Delete, and Update do not work. The user guide uses the directFn (instead of the api) to perform read operations. It would really helpful if the example code had a full API CRUD example.

I'm using a DirectProxy instead of the HttpProxy. The api read and destroy methods are @DirectMethod, the update and create are a @DirectFormPostMethod.

The read works fine and returns an ID, but the delete does not send an ID. I have the idProperty defined in my JsonReader. The only variation I have is the DirectProxy in place of the examples HttpProxy and directjngine.1.2 as my back-end. I'm pulling the same ext libraries as the example.

This only works with the AppEngine SDK's 1.2.5 and older... Basically, after 1.2.5, the SDK will detect a policy exception in the Development environment too (attempt to write to the file system) and immediately take the web application off-line. This use to happen only in production, but the development environment could write files. This is the reason the code above works. When I'm developing, the API is updated then when deployed it does not even try it...

Now, Google made the SDK smarter. This is better as it would trap these things earlier before you try to deploy code that is not going to work. It breaks the fix though because I can't update the API file at development time anymore.

I see the API configuration is in the web.xml. Can you add a interface for the API caching? Is this easy? The default can use the file based code you have now. An implementation for the Google MemCatch would be a great way to solve this... If you want it in your code, I could write one using reflection so it would not create any compile time dependencies on the AppEngine SDK. Otherwise, I can just change the web.xml to use my implementation and still easily get directjngine upgrades.

DirectJNgine and AppEngine

I needed to make only one change to directjngine so it would run in AppEngine.

Have you tried to execute all tests in the djn_test app when running in AppEngine?
This is a security check one should always perform when modifying DJN, to catch subtle issues.

Do the tests pass with your proposed changes? Currently, I just can't pass the file upload tests (both automated and manual), all other test pass -after I made some adjustments to generate/provide the api on the fly, instead of generating js files.

Small as this issue might seem, I do not want to commit code to DJN that does not pass all tests. Since I'm not an AppEngine user I might be missing something... Any clues?

If all of this is working currently for you, I will consider adding official support for AppEngine, which would be a nice feature :-). That would be great!

directjngine

Have you tried to execute all tests in the djn_test app when running in AppEngine?
This is a security check one should always perform when modifying DJN, to catch subtle issues.

Do the tests pass with your proposed changes? Currently, I just can't pass the file upload tests (both automated and manual), all other test pass -after I made some adjustments to generate/provide the api on the fly, instead of generating js files.

Small as this issue might seem, I do not want to commit code to DJN that does not pass all tests. Since I'm not an AppEngine user I might be missing something... Any clues?

If all of this is working currently for you, I will consider adding official support for AppEngine, which would be a nice feature :-). That would be great!

Regards

Noted .. I like those unit tests. I'll keep that in mind. I'm not proposing that the change should go into your code though. It does not work on the newer AppEngine SDKs. They are changing very fast; the public Java environment at Google is still very new. I posted the code change in-case someone needs to make a hack to get it to work in the mean time.
I'll checkout your code changes to generate the API on the fly. I need a better solution is needed first.

I noticed an Array index exception when using the DirectProxy with directjngine. Do you support the DirectProxy yet?

Noted .. I like those unit tests. I'll keep that in mind. I'm not proposing that the change should go into your code though. It does not work on the newer AppEngine SDKs. They are changing very fast; the public Java environment at Google is still very new. I posted the code change in-case someone needs to make a hack to get it to work in the mean time.
I'll checkout your code changes to generate the API on the fly. I need a better solution is needed first.

The point is, I will not generate the api on the fly unless there is a need, because generating a physical .js file make it easier for the server to avoid a transfer by telling the browser the file hasn't changed, instead of sending it. Optimization is a big concern for me.

In fact, I tried generating the api on the fly only to support AppEngine (!): if I can't fully support all ExtDirect functionality in AppEngine, then there is not point in making DJN more bloated and complicated to "support in half" something else.

If you come across a solution to the file upload support in AppEngine, I will love to hear from you, so that the whole community can benefit from our effort :-)

I noticed an Array index exception when using the DirectProxy with directjngine. Do you support the DirectProxy yet?

DJN just supports a communication protocol, not that it supports DirectProxy or some other class in ExtJs. It implements all of the ExtDirect 1.0 specification, and that means that it should support all ExtJs components that rely on the specification.

But maybe you have come across some bug that is only made apparent when using that component. Provide a detailed report (Java stack trace, the log with the data sent to the server, the simplest Java and JavaScript source that shows the behavior), and then we will be able to take a look at it.

Pedro - there have been a few Wicket questions on this board but I didn't see any specifically addressing these questions: Have you tried - or do you know of those who have tried - to integrate DJN with the Wicket framework? If not, and if you know how Wicket works, do you have a "best suggestion" on broadly how to do so?

Pedro - there have been a few Wicket questions on this board but I didn't see any specifically addressing these questions: Have you tried - or do you know of those who have tried - to integrate DJN with the Wicket framework? If not, and if you know how Wicket works, do you have a "best suggestion" on broadly how to do so?

I have used Wicket, but never attempted to integrate ExtJs with it.

To me, it seems like a very difficult thing to do because of the philosophical differences between ExtJs and Wicket. I think attempting deep integration will cause very many headaches.

That said, one of my co-workers has used ExtJs with Wicket for things such as dialogs, tabs, etc., but *never* integrating them deeply -and, to be fair, at a big cost in time and energy.