I'm not sure I understand. DI can help to set EntityListenerFactory but how
would it help in this common case: to map listeners for usage on client?
This should be done in modeler without any extra code and configuration
2009/11/19 Andrus Adamchik <andru..bjectstyle.org>
>
> 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
>
>
-- Andrey
This archive was generated by hypermail 2.0.0 : Thu Nov 19 2009 - 04:51:44 EST