In this post I will consider features which I consider just “nice to have” and therefore not a must.
Nice to have features
Enhancements to unexpected server exception handling
Right now, when there is an unexpected exception at the server, DJN provides a
message, as per the Ext Direct specification.
While this message provides both the exception type (without the package) and the exception message, I would like to have them apart. This way, it would be possible to handle exceptions without having to dissect the message, making things easier.
Besides, I would love to return the whole exception chain, if in a limited way: just the exception type and the message for every exception in the chain would be enough.
My proposal is return
serverExceptionwith the error information, that would provide the following entries:
exception.type: the full exception name of the topmost exception.
exception.message: the message of the topmost exception.
rootException.type: the full exception name of the root exception.
rootException.message: the message of the root exception.
exceptions: an array of elements containing the
messagefor all exceptions in the exception chain.
It is important to understand that serializing all exception information looks nice but is not a good idea. What if we find an exception with an structure whose serialization is not feasible? Then we would get the ugly scenario of an error inside of an error handler. You really don’t want that to happen, believe me!
Better not to try: I think that getting the types and messages of the whole stack of exceptions is enough for 99% of the cases.
Support client-based polymorphic objects
Ok, you’ve got a nice user interface that allows you to handle projects and complex projects. Looks like they both should be inheriting from a base project class, right? Now, how do you handle that in the server side? If you write a method that receives a base project, then, how is DJN/Gson to know the exact class to which a json object belongs?
This is a feature that is relevant for some projects with rich object models, but I really need to ruminate about it a lot more.
Sencha IDE support: this one is nice too, but there has been very little demand for it, strange as it might seem.
And, I don’t use Sencha’s IDE: they gave me a free license for their first version so that I might support it, but since then I’ve got nothing else that an offer for a discount for the new version. I thought they would keep sending it for free to contributors like me, but that’s not the case: I would be crazy to pay for a product I will not use…except to provide free support for it. Yup! Writing Open Source is hard🙂.
Besides, not having committed to support it and not knowing what will happen when newer version appear, I don’t feel like asking Sencha for the new IDE.
Method interception, so that you can call your own code before and after the Java method itself is called to perform security checks or… You get the idea.
Well, this is already supported, just that I have not publicized it. I think this feature deserves its own post.
For those of you who are interested, take a look at how
SsmDispatcheris implemented and used, as well as to
CDI & JEE Integration
Tracking appengine to make sure the last version is supported.
There is another feature that feels very important to me, but I have not discussed here: implementing serialization control.
For rich object models it can happen that too many unneeded objects are sent to the server because the object model is a giant net of interconnected objects. You need to limit what is serialized in that scenario. When you consider this, as well as interaction with JPA lazy loading, or you take into account the need to exclude some sensitive data, you can see that things can get really complex.
This feature deserves a whole post, and this one is already too long.