service dispatcher map context just like GenericEntity

[Adam Heath <do...@brainfood.com>]

The parameters to a service are a list of names, and the types of
those parameters.  This is very similar to a GenericEntity.
GenericEntity is a map, that has special methods for fetching
type-specific values(getLong, getBigDecimal, etc).

Wouldn't it be nice to have type-specific maps passed to java-based
services?

My idea would introduce a GenericContext, used by both entity and
service.  This context would be read-only.  There would be a model
that defined the java types for each value.

The entity system would extend the java type definitions, to attach
the sql version of the backing store.  It would also extend
GenericContext to be writable.

The service engine would the do similar things.  Incoming service
calls could define that they'd like to take a GenericContext, instead
of a map.  It would also extend the service model to support incoming
GenericContext type-specific methods.

Also, while doing all this, I'd like to move the specification of
default values from service code, into the definition.  I've found
code like this:

if (!context.containsKey("someParameter")) {
  context.put("someParameter", defaultValue);
}

or

Object value = context.get("someParameter");
if (value == null) {
  value = defaultValue;
}


The former is broken, as it tries to write a value into the context.
The context is supposed to be read-only.

Re: service dispatcher map context just like GenericEntity

[Adrian Crum <ad...@hlmksw.com>]

I suggested this a while ago and it got a mixed response. I started 
writing code for it in case there was any interest. I can post that code 
to Jira if you would like me to.

I started off with a Parameters class that is a simple wrapper around a 
Map. The class has typed accessors and it is writable. The Parameters 
class can be subclassed into type-specific contexts: RequestContext, 
ServiceContext, ScreenContext, MethodContext, etc.

 From my perspective, the advantage of typed contexts is the ability to 
add type-specific behaviors to them.

If the idea makes its way into the project, the context must be writable 
at first - generating a warning when modified. This is because a lot of 
code modifies the context and the parameters Map it contains.

In addition, I think the context should throw an exception if client 
code attempts to retrieve a parameter that is not in the service definition.

-Adrian

On 12/11/2010 12:57 PM, Adam Heath wrote:
> The parameters to a service are a list of names, and the types of
> those parameters.  This is very similar to a GenericEntity.
> GenericEntity is a map, that has special methods for fetching
> type-specific values(getLong, getBigDecimal, etc).
>
> Wouldn't it be nice to have type-specific maps passed to java-based
> services?
>
> My idea would introduce a GenericContext, used by both entity and
> service.  This context would be read-only.  There would be a model
> that defined the java types for each value.
>
> The entity system would extend the java type definitions, to attach
> the sql version of the backing store.  It would also extend
> GenericContext to be writable.
>
> The service engine would the do similar things.  Incoming service
> calls could define that they'd like to take a GenericContext, instead
> of a map.  It would also extend the service model to support incoming
> GenericContext type-specific methods.
>
> Also, while doing all this, I'd like to move the specification of
> default values from service code, into the definition.  I've found
> code like this:
>
> if (!context.containsKey("someParameter")) {
>    context.put("someParameter", defaultValue);
> }
>
> or
>
> Object value = context.get("someParameter");
> if (value == null) {
>    value = defaultValue;
> }
>
>
> The former is broken, as it tries to write a value into the context.
> The context is supposed to be read-only.
>