Hi Jesse,
> seems like that's worth a patch of code to wonder, no?
Perhaps, but not in its current form, as it's quite specific.
> I think a lot of people have diverging implementations that could use
> consolidation and I'd like to move to something more common between
> everyone myself, so I'd like to see that happen if it can be done in such
> a way that makes sense.
Sure thing. My requirements are specific - region and bucket info coming
from the db, determined by ownership/client/what-have-you. Link-lifes
determined at runtime. This is probably not everyone's aim, so yes, we'd
need to determine common intentions. Mine are, well, in this thread.
I think other people may want to persist object acls at some point. There
are other considerations.
Is this list the correct space to be discussing this, or is there another
setting more appropriate?
Cheers,
Matt
> On Oct 24, 2011, at 6:59 PM, Matthew Ness wrote:
>
>>> Hi all,
>>>
>>> I'm using ERAttachments in a couple of my applications. Some are using
>>> the
>>> configuration type {S3}.
>>>
>>> For one of the applications using S3 I have a need to dynamically
>>> generate
>>> and use a sub-set of the ERAttachment configuration set. I cannot use
>>> the
>>> standard Properties approach, as the ERAttachments are not
>>> grouped/configured by the standard EO->ERAttachment relationship but
>>> other
>>> factors.
>>>
>>> That is, for any specific EO->ERAttachment relationship, there may be
>>> multiple configurations (defined by, say, ownership), and new
>>> configurations may be added over the course of the running app. The
>>> major
>>> (but not only) difference being the S3 bucket the ERAttachment will
>>> use.
>>>
>>> I realise I can send a configuration name to ERS3AttachmentProcessor,
>>> but
>>> that reads the bucket name from ERXProperties, rather than another type
>>> of
>>> persistence (in my case, db).
>>>
>>> I have in mind subclassing ERS3AttachmentProcessor, reading my
>>> configuration data based on my criteria, and processing the
>>> ERAttachment
>>> in that subclass based on that criteria. This seems to me a reasonable
>>> way
>>> to go, but maybe I'm missing something.
>>>
>>> Does this seem like a sound approach? Would you recommend an alternate
>>> approach, or am I missing something? Has anyone done something similar?
>>> Would it make more sense to not subclass, and assign my new class in
>>> ERAttachmentProcessor.addAttachmentProcessorForType?
>>>
>>> Likewise, I'd like to dynamically assign the linkLife of a generated
>>> URI
>>> of an S3 ERAttachment. On the face of it, it looks like I may need to
>>> build a new [My]S3Attachment/[My]AttachmentProcessor stack. Or is there
>>> another way to dynamically assign the linkLife each time an S3 URI is
>>> generated in ERAttachment?
>>>
>>> Lastly, this approach could allow the persistence of the acl value at
>>> creation time, but this may be a discussion for another time :)
>>>
>>> Thanks for any help,
>>>
>>> Matt
>>
>>
>>
>> Hi again,
>>
>> For what it's worth, I created a new attachment processor class and
>> subsidiary classes which deal with AWS regions, buckets, and linkLifes
>> to
>> satisfy my requirements listed above. In my Application's
>> finishInitialization I assigned this new processor to the
>> ERS3Attachment.STORAGE_TYPE value. If anyone ever does something similar
>> I'd be happy to help them out.
>>
>> Cheers,
>>
>> Matt
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com
>>
>> This email sent to jtay...@oeinc.com
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
