FAQ

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

Search Discussions

  • Andrey Razumovsky at Nov 19, 2009 at 9:51 am
    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 <andrus@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
  • Andrus Adamchik at Nov 19, 2009 at 10:09 am

    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
  • Andrus Adamchik at Nov 19, 2009 at 10:14 am

    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 Razumovsky at Nov 19, 2009 at 10:21 am
    If so, it also means we should get rid of two sets of classes at first step

    2009/11/19 Andrus Adamchik <andrus@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
  • Andrus Adamchik at Nov 19, 2009 at 10:33 am
    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 <andrus@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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedNov 19, '09 at 8:49a
activeNov 19, '09 at 10:33a
posts6
users2
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase