ERAttachments, S3, and dynamic configurations
ERAttachments, S3, and dynamic configurations
- Subject: ERAttachments, S3, and dynamic configurations
- From: Matthew Ness <email@hidden>
- Date: Tue, 18 Oct 2011 09:52:14 +1100
- Importance: Normal
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
_______________________________________________
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