Re: Tapestry + relationship-backed form components

From: Eric Schneider (eri..entralparksoftware.com)
Date: Tue Jul 13 2004 - 16:39:28 EDT

  • Next message: Andrus Adamchik: "Re: Tapestry + relationship-backed form components"

    Robert,

    There's nothing wrong with your validateForSave() approach, but it's
    far from ideal. It's really stretching the domain validateForSave()
    for was intended for. But, if it works it works.

    Again, I think these workarounds will be temporary. Newer versions
    will address this.

    Cheers,
    Eric

    On Jul 13, 2004, at 4:24 PM, Robert Zeigler wrote:

    > Eric Schneider wrote:
    >> Robert,
    >> I've run into similar problems. Andrus and I talked about it, and
    >> it something that will probably be handled by Cayenne in future
    >> versions. It would be helpful in certain scenarios to set related
    >> objects (that are registered) on transient objects (that are not
    >> registered yet).
    >> Unfortunately, I don't know of an elegant elegant solution. I can
    >> think of a couple of approaches, but they both leave open the
    >> opportunity for shittiness.
    >> If you register the new object before you you get to form page, you
    >> can make every action (aside from the form's save) rollback the
    >> changes on the data context. This approach works, but falls short
    >> when users click the back button off the form page. :-\
    >> Another suckie option would be to break your form up into two pages.
    >> One to set top level properties on your object. A second to set the
    >> relationships once the object is registered. Again, not really
    >> ideal.
    >> e.
    >
    >
    > Well, at least it's good to know that I'm not just missing something
    > about cayenne. =)
    > As far as solutions, I've done both of what you mentioned, actually. ;)
    > I also have properties on most objects that are set in the code and
    > only
    > set right before the save, so, for most objects, I can override
    > validateForSave, have it check for null for those values, and have the
    > object unregister itself from the data context when they aren't set. In
    > my current application, most scenarios can be handled this way; are
    > there any drawbacks/side effects I should be aware of in doing things
    > this way? Thanks for the help!
    >
    > Robert
    >



    This archive was generated by hypermail 2.0.0 : Tue Jul 13 2004 - 16:40:38 EDT