ah, just what I was looking for. maybe put something like that in my app Application() initialization?
On Aug 2, 2013, at 8:27 PM, Matt Ness <[email protected]> wrote: > > If you are using the static processor(s), you can get the static processor by > calling ERAttachmentProcessor.processorForType(your type). > > Then setDelegate() on the processor. > > > > > On 03/08/2013, at 10:16 AM, Jesse Tayler <[email protected]> wrote: > >> >> ah, thanks - I see. >> >> I was using a method via REST that called the attachment processor, but I >> guess in my web/d2w app it is relying on my properties setting? >> >> er.attachment.storageType=s3 >> >> should I set the delegate in a specific way since I don’t seem to have >> access to the created processor? a default delegate or shared processor >> somewhere? >> >> >> >> On Aug 2, 2013, at 7:47 PM, Matt Ness <[email protected]> wrote: >> >>> Hi Jesse, >>> >>> Your processor delegate has the attachmentAvailable() interface method. >>> >>> >>> >>> On 03/08/2013, at 9:27 AM, Jesse Tayler <[email protected]> wrote: >>> >>>> >>>> Agreed >>>> >>>> This really should be done on completion of the otherwise successful S3 >>>> attachment push, it would seem. >>>> >>>> Is there a call, or notification I should be attending in ERAttachemnt for >>>> such? >>>> >>>> >>>> >>>> On Aug 2, 2013, at 6:53 PM, Ramsey Gurley <[email protected]> wrote: >>>> >>>>> Never make side effects in your getter/setters. Definitely do not >>>>> override takeStoredValueForKey. John's recommendation of didInsert sounds >>>>> like the proper place in the EO lifecycle to call it, assuming this is >>>>> actually model logic. Using the intermediate entity as David suggested is >>>>> what I always do for ERAttachments. Do generate an entity class. As for >>>>> awakeFromInsertion, unlearn what you have learned. Use wonder's init() >>>>> instead. awakeFromInsertion can be called more than once due to bugs in >>>>> EOF. That's the reason init() exists. >>>>> >>>>> My 2¢ :-) >>>>> >>>>> On Aug 2, 2013, at 3:25 PM, Jesse Tayler wrote: >>>>> >>>>>> Thanks Tim, >>>>>> >>>>>> I can readily see that I’d have been well advised to use an interim >>>>>> entity like “Document” or something. >>>>>> >>>>>> sigh. >>>>>> >>>>>> I’m guessing it’s not a good idea to try and make the ERAttachment a >>>>>> subclass or EO of my own. >>>>>> >>>>>> maybe I should use the takeStoredValueForKey, check if the key is a >>>>>> change in the poster relationship and then fire the script? >>>>>> >>>>>> that might preserve the model, while firing the script only when the >>>>>> save is a change on the relationship? >>>>>> >>>>>> >>>>>> >>>>>> On Aug 2, 2013, at 2:41 PM, Timothy Worman <[email protected]> wrote: >>>>>> >>>>>>> Your override would not be called if the updating process is using >>>>>>> takeStoredValueForKey. >>>>>>> >>>>>>> Tim >>>>>>> UCLA GSE&IS >>>>>>> >>>>>>> On Aug 2, 2013, at 10:21 AM, 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/lists%40thetimmy.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/rgurley%40smarthealth.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/matt%40logicsquad.net >>>> >>>> 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]
