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 <[email protected]> > > 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
