I always model the ERAttachment as an entity, then have the relationship to ERAttachment from there.
Document -> ERAttachment This gives you an opportunity to add additional metadata about the uploaded file if you wish. Oh yes and add some nice BL :-) On 2013-08-02, at 11:48 AM, Jesse Tayler <[email protected]> wrote: > Thanks > > For some reason, the poster is just an ERAttachment, but I suppose I should > just generate a class for it, in whatever case — > > > > > On Aug 2, 2013, at 2:43 PM, John Huss <[email protected]> wrote: > >> You can override didInsert in your Poster EO class. >> >> >> On Fri, Aug 2, 2013 at 1:39 PM, Jesse Tayler <[email protected]> wrote: >> >> it likely should be another way entirely, but I don’t think the primary key >> would be already set at that time unless I saved changes during the >> relationship setter which might be both dangerous and obtuse. >> >> >> >> On Aug 2, 2013, at 2:25 PM, Theodore Petrosky <[email protected]> wrote: >> >> > the awake method may be better, but shouldn't this be >> > >> > but you would have to override the original signature. >> > >> > public void setPoster(com.something.Poster value) { >> > NSLog.out.appendln(" com.something.Poster this is the override " + >> > value); >> > takeStoredValueForKey(value, _Poster.POSTER_KEY); >> > } >> > >> > I just played with this and it works. But I'm willing to bet there is a >> > good reason (that I don't know) not to do it. >> > >> > Ted >> > >> > On Aug 2, 2013, at 1:21 PM, Jesse Tayler <[email protected]> wrote: >> > >> >> >> >> I have an override of a normal EO setter, but for some reason, it isn’t >> >> called but the value does get updated >> >> >> >> I really just want to fire off a unix process once a new posterId has >> >> been set, so maybe there’s a smarter way but I thought this would be >> >> reliably called once and only after there’s a known primary key id for >> >> that poster (ERAttachment) >> >> >> >> Any thoughts on that? >> >> >> >> >> >> @Override >> >> public void setPosterId(Integer value) { >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Do not post admin requests to the list. They will be ignored. >> >> Webobjects-dev mailing list ([email protected]) >> >> Help/Unsubscribe/Update your Subscription: >> >> https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com >> >> >> >> This email sent to [email protected] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com >> >> This email sent to [email protected] >> >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/programmingosx%40mac.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
