Re: @Override of EO?
Re: @Override of EO?
- Subject: Re: @Override of EO?
- From: Matt Ness <email@hidden>
- Date: Sat, 03 Aug 2013 10:27:50 +1000
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@hidden> 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@hidden> wrote:
>
>> Hi Jesse,
>>
>> Your processor delegate has the attachmentAvailable() interface method.
>>
>>
>>
>> On 03/08/2013, at 9:27 AM, Jesse Tayler <email@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden