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]
