You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrey Razumovsky <ra...@gmail.com> on 2009/11/19 10:50:50 UTC
Re: [jira] Commented: (CAY-1312) Allow lifecycle callbacks on ROP
client
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 <an...@objectstyle.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
Re: [jira] Commented: (CAY-1312) Allow lifecycle callbacks on ROP client
Posted by Andrus Adamchik <an...@objectstyle.org>.
I think this is a somewhat parallel task. I.e. I have no problem with
2 sets of listeners (server and client) in the Model, just not more
than that.
Andrus
On Nov 19, 2009, at 12:20 PM, Andrey Razumovsky wrote:
> If so, it also means we should get rid of two sets of classes at
> first step
>
> 2009/11/19 Andrus Adamchik <an...@objectstyle.org>
>
>>
>> On Nov 19, 2009, at 12:09 PM, Andrus Adamchik wrote:
>>
>> This should be done in modeler without any extra code and
>> configuration
>>>>
>>>
>>> In a modularized application, the model and associated DataObjects
>>> are
>>> created once and then reused in many (possibly unexpected) scenarios
>>>
>>
>> To stress this point, this is similar to why you'd have inheritance
>> and
>> composition in an OO language - you don't want all possible
>> scenarios to be
>> addressed in a single class (or file), with a long chain of if/else.
>>
>> Configuration (model) reuse is facing the same problems.
>>
>> Andrus
>>
>>
>
>
> --
> Andrey
Re: [jira] Commented: (CAY-1312) Allow lifecycle callbacks on ROP
client
Posted by Andrey Razumovsky <ra...@gmail.com>.
If so, it also means we should get rid of two sets of classes at first step
2009/11/19 Andrus Adamchik <an...@objectstyle.org>
>
> On Nov 19, 2009, at 12:09 PM, Andrus Adamchik wrote:
>
> This should be done in modeler without any extra code and configuration
>>>
>>
>> In a modularized application, the model and associated DataObjects are
>> created once and then reused in many (possibly unexpected) scenarios
>>
>
> To stress this point, this is similar to why you'd have inheritance and
> composition in an OO language - you don't want all possible scenarios to be
> addressed in a single class (or file), with a long chain of if/else.
>
> Configuration (model) reuse is facing the same problems.
>
> Andrus
>
>
--
Andrey
Re: [jira] Commented: (CAY-1312) Allow lifecycle callbacks on ROP client
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 19, 2009, at 12:09 PM, Andrus Adamchik wrote:
>> This should be done in modeler without any extra code and
>> configuration
>
> In a modularized application, the model and associated DataObjects
> are created once and then reused in many (possibly unexpected)
> scenarios
To stress this point, this is similar to why you'd have inheritance
and composition in an OO language - you don't want all possible
scenarios to be addressed in a single class (or file), with a long
chain of if/else.
Configuration (model) reuse is facing the same problems.
Andrus
Re: [jira] Commented: (CAY-1312) Allow lifecycle callbacks on ROP client
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 19, 2009, at 11:50 AM, Andrey Razumovsky wrote:
>
> 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?
I guess the point is not so much DI, but rather registering listeners
via API in some form. (Although client-side DI may also be beneficial
in general).
> This should be done in modeler without any extra code and
> configuration
In a modularized application, the model and associated DataObjects are
created once and then reused in many (possibly unexpected) scenarios.
So my first solution to this was to allow extra DataMaps to be merged
with the main reusable DataMap, overriding/adding listeners (so in
this case we'll need to support "override ObjEntities" in the Modeler).
My second solution is to do this via API. It is possible to do it now
as well. DI container will just make it more centralized in each
application module.
The only reason that I am more in favor of a second solution is that I
want minimize modeling effort (same reasons why I want an Eclipse
plugin - want all the project pieces in a single environment). I guess
we just need to try and play with API and see if we can make it easy
to use (and then comprehend your configuration) in a modularized app
environment.
Andrus