Re: Initial questions, thoughts & suggestions

From: Magic Hat (magic_ha..ac.com)
Date: Mon Sep 02 2002 - 14:55:10 EDT

  • Next message: Holger Hoffstätte: "cayenne-cvs vs. eclipse"

    Hi Andrus,

    On Monday, September 2, 2002, at 08:29 , Andrus wrote:

    > thanks a lot for offering help ;-). Like I said we need it, especially
    > from people who really understand the underlying concepts.

    I don't know if I qualify, but my pleasure in any case.

    > I would suggest that invocation of validation methods should be
    > external to DataObject. If we are talking about persistence for
    > arbitrary classes in the future, we don't want to force yet another
    > interface on the class implementors.

    Yes. That is what I was thinking: a totally generic validation mechanism.

    > Maybe the object being validated may implement "validateXProperty"
    > methods (without implementing any particular interface), but the actual
    > invocation code should be in a separate class.

    Yep. When I mentioned NSValidation, it was more in regard to the default
    implementation, not about yet another interface.

    > Same with EOValidation-like functionality for insert/delete/update.

    Yes, but that's a little bit more specific. And could be also handled
    through "self delegation" perhaps: something like willInsert(),
    validateForInsert(), didInsert() and so on. I'm always missing all the
    "will" and "did" callback in EOF.

    >
    > I wonder if something like Jakarta DynaBeans would be a good starting
    > point for such implementation?

    I will check it out. But I have much of the infrastructure already in
    place. Will see.

    > - delegates that are notified *before* something is about to happen, so
    > that they can affect the flow

    I have a little implementation of NSInvocation. Very handy for handling
    delegation. Let me know if you are interested.

    > - notifications that are sent to observers about various events after
    > the fact. This is where your notification center might be needed. What
    > do you use for distributed notifications? HTTP? Sockets? Multicast?

    Multicast.

    > We may also look into other ways for distributed notifications. I
    > think TopLink uses JMS for that. Cause if we ever get into cache
    > synchronization, message flow will be overwhelming.

    Multicast is pretty lightweight. But I agree that having a JMS compliant
    notification center would be ideal. In the meantime, multicast is very
    straightforward.

    >
    > In any event, I guess we may start with defining the events needed.

    Yep. The more the merrier :-)

    Cheers,

    PA.



    This archive was generated by hypermail 2.0.0 : Mon Sep 02 2002 - 14:55:19 EDT