On the rest backend we would like to use the standard Java JSR311 Response Object to deal with the appropriate HTTP status codes to deal with known error conditions e.g. duplicate client created.

For example:

try {
   delegate.doSomething(somethingId);
} catch (IndexException e) {
   Response.ResponseBuilder builder =
   Response.status(Response.Status.CONFLICT);
   builder.type("application/json");
   builder.entity("<error>Could not do something, something already exists</error>");
   throw new WebApplicationException(e, builder.build());
}

This means that the enterprise framework needs to be sensitive to the Status Code of the response message and before it publishes the message back to the topic adapts the Status Code to a set of flags which keeps the subscriber ignorant of the present of HTTP Codes but allows it to respond in an widget specific way depending on what the response was.

Initially the codes needed are:

• 200 OK
• 409 CONFLICT

Where previously in 1.6 compliant code you would have example usage of dojo base like:

dojo.mixin(...)

this needs to be a reference to the param name of the discreet dojo module that is now used:

dojo.lang.mixin

Grumble grumble

Either in scripts or a section on the readme to add the setup.sh pulls to a .gitignore.

Currently, you have to create the full path of a topic in a widget.
_Widget should do:

this.TOPIC_NAMESPACE = this.declaredClass - but with . replaces with / and a leading /

Then _Widget could have an addTopic method

this.addTopic(someTopic);

would create an addition to this.pubList in the form [this.TOPIC_NAMESPACE][someTopic]

Work out how to do dojo.declare inline in a doh test.

Do you have any plans to port this to Dojo 2?

ObjectValidator should only validate objects if release = false.

Should we combine the population of a pubList or subList with the dojo.subscribe?
Currently we do:

this.subList.NEW_TOPIC = '/some/topic/name';
dojo.subscribe(this.subList.NEW_TOPIC, this, this._handleResponseFromSomeNewTopic);

Maybe we do:

var newTopic = {topic: '/some/new/topic', handler: this._handleResponseFromSomeNewTopic, scope: this};
this.subList.NEW_TOPIC = newTopic;

Then in _Widget, we can iterate over the pub and sub lists and create the dojo.subscribes).

XhrTransport should create the ObjectStateWrapper from the REST response using the code that is currently in the Ctor of Response.

At present the framwork only seems to support xhrPost. In order to fullly utilize a rest application backend we need to be able to get, put and delete resources.

Change setup.sh to be passed project path of an existing project that you want to pull in resources for.
This way, people can install dojoEnterpriseApp and use the scripts to create an application and then run setup.sh to pull in the deps for the new application. This would mean that we would offer and option to copy the scripts around to created projects as one centralised copy has its advantages - but versioning might require separate scripts as well.

Fix scoping issue so we dont clobber dojo.connect.

It would be useful to have an mixin specifically at the Application widget level.

This would provide specific functionality to alllow an application widget to autowire itself as a subscriber to any topics that are declared as publish topics from any of it's 'child' widgets.

There may be some constraints around declaritive introduction of child widgets that this mixin needs to be able to accomodate, furthermore manual registration to topics should still be possible for adhoc wiring.

The contents of src/js/app should be automatically added to git (if using git integration). Also index.html should be added.

You should be able to override directories that already contain an application.

We should check that params is not null when passed to a transport implementation. If it is we should create an empty object.

When you have created an application or widget using the scripts, these can be added to SCC.
However, if you pull a widget or app from SCC, then you need to install around the widget, all the dependencies pulled in by setup.sh.

Add websocket flag to app json in LoginResoponse. By convention, the client should listen on the root of the baseUrl for an application:

{baseUrl: '/someContext/foo/bar', websocket: true}

means that a websocket listener will be created for '/someContext/foo/bar' for the application.
Anything routed to this URL will be broadcast on the topic {application.id/push}.