On Nov 19, 2009, at 10:09 AM, Andrey Razumovsky (JIRA) wrote:
> On Nov 19, 2009, at 12:42 AM, Ari Maniatis (JIRA) wrote:
>> Just throwing this out as an idea: would users sometimes want to
>> specify particular clients? For instance, you might have a data
>> processing node which is different to a client GUI node or a (in
>> the future) Cayenne aware Ajax node.
>>
>> If so, the schema would allow for this to be arbitrary text (not an
>> enumeration), but the modeler would by default give you three
>> options (as you specified) and maybe (later) a free entry text
>> option.
>
> Makes sense, but generating LifecyleCallbackRegistry for client
> should be as simple as possible, i.e. without any extra parameters
> for connection.
> How then shall we decide what listeners are sent to ROP client?
> Comparing strings is not so safe as comparing enums. So I would
> suggest adding this logic to a listener itself, e.g. adding
> checkings for client "type" in callback method
I think this problem is more general than that, and it will be hard to
address it via the mapping.
I am often running in a situation with server-side objects that
require different sets of listeners in different applications using
the same common mapping. In fact in many cases the listener class is
defined outside the jar file containing the mapping, and is therefore
available to some war's but not others.
In 3.0 I am using EntityListenerFactory as a stop gap measure, but I
want something easier to use... Again I am hoping that DI approach
would allow for simple listener extensions.
But I am unsure that we need to further complicate the mapping, since
it makes it less reusable.
Andrus
This archive was generated by hypermail 2.0.0 : Thu Nov 19 2009 - 03:49:20 EST