Hi Hugi, The problem you’re trying to solve looks like a cross cutting concern [1]. You could use an aspect-oriented framework to encapsulate this kind of logic into aspects. AspectJ [2] is probably the most popular framework in this area. If your requirements aren't too high, you can also create simple aspects using WOInject+Guice [3][4] frameworks.
Of course, using aspects in your application adds a new level of complexity that you should consider. [1]http://en.wikipedia.org/wiki/Cross-cutting_concern [2]http://eclipse.org/aspectj/ [3]https://code.google.com/p/google-guice/wiki/AOP [4]http://hprange.github.io/woinject/ Cheers, Henrique On 04/12/2013, at 09:57, Hugi Thordarson <[email protected]> wrote: > Does anyone do WO without Wonder anymore? :) > > But that’s an excellent suggestion, although I’d still prefer to be able to > do this without introducing the EC subclass. > > Slight problem though—in my simplified example I didn’t mention that the > mechanism also needs to handle modifications to objects (for attributes such > as modificationDate and modifiedByUser) and I don’t believe I can hook into > object modifications via an EC subclass. Perhaps I’ll just bite the bullet > and handle modifications just before save (using > EditingContextWillSaveChangesNotification). > > Cheers, > - hugi > > > > On 4.12.2013, at 11:26, Bogdan Zlatanov <[email protected]> wrote: > >> Hi Hugi, >> >> I was going to suggest something along the lines of : >> >> /** >> * A custom EOEditingContext >> */ >> public class HugiEC extends ERXEC { >> @Override >> public void insertObject(EOEnterpriseObject eo) { >> super.insertObject(eo); >> if (eo instanceof Timestamped) { >> // … create EO timestamp >> } >> } >> } >> >> that can then be plugged in via Wonder via >> er.extensions.ERXEC.editingContextClassName=whatever.package.HugiEC >> >> But I don’t know if you’d like the Wonder dependency. >> >> Cheers, >> Bogdan >> >> On 4 Dec 2013, at 11:52, Hugi Thordarson <[email protected]> wrote: >> >>> Hi Johann, >>> >>> Thanks for the idea, but the framework is meant for wider distribution so >>> I’d rather not have it depend on a modified superclass template. >>> >>> Cheers, >>> - hugi >>> >>> >>> On 4.12.2013, at 10:42, Johann Werner <[email protected]> wrote: >>> >>>> Hi Hugi, >>>> >>>> a simple – though perhaps not as elegant as you want – solution would be >>>> to create your own EO superclass and override init() (from >>>> ERXGenericRecord) where you put your logic: >>>> >>>> @Override >>>> protected voit init(EOEditingContext ec) { >>>> super.init(ec); >>>> if (this instanceof TimeStamped) { >>>> setCreationDate(new NSTimestamp()); >>>> … >>>> } >>>> } >>>> >>>> You can configure EOGenerator to use your class instead of EOGenericRecord >>>> so this would be a do it once and forget ;-) >>>> >>>> HTH >>>> jw >>>> >>>> >>>> Am 04.12.2013 um 10:18 schrieb Hugi Thordarson <[email protected]>: >>>> >>>>> Hi all. >>>>> >>>>> I’ve been attempting to automate the setting of some common attributes in >>>>> my EOs, like creationDate, createdByUser etc. etc. Usually one might >>>>> populate attributes like that in awakeFromInsertion, but that's >>>>> boilerplate I’d rather not add to my EO classes. So instead, I’ve taken a >>>>> different route. Simple example: >>>>> >>>>> I have an interface TimeStamped, objects that I want stamped with the >>>>> creation date implement this interface. My application then listens for >>>>> EOEditingContext.ObjectsChangedInEditingContextNotification and when it’s >>>>> received, I iterate through inserted objects, check if they implement >>>>> TimeStamped and update their creation dates. >>>>> >>>>> This works fine, apart from a little kink: The >>>>> EOEditingContext.ObjectsChangedInEditingContextNotification is not >>>>> broadcast until WO calls processRecentChanges on the EditingContext—and >>>>> that happens at the *end* of the r/r-loop. This means that if I create an >>>>> object, assign it to a page and return it, WO will happily render the >>>>> page, and THEN stamp the values on the EO (which are thus not shown until >>>>> the user next refreshes the page). >>>>> >>>>> I’m aware I can expedite the broadcasting of the notification by manually >>>>> invoking processRecentChanges before returning the page—but that kind of >>>>> ruins the whole “get this functionality out of my face” aspect of the >>>>> mechanism. >>>>> >>>>> Anyone have any happy litle ideas on how to tackle the problem? >>>>> >>>>> Cheers, >>>>> - hugi >>>>> >>>>> // Hugi Þórðarson >>>>> // Góður kóði >>>>> // 895-6688 / 561-0896 >>>> >>>> >>> >>> _______________________________________________ >>> 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/bogdan.zlatanov%40gmail.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/hprange%40gmail.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/archive%40mail-archive.com This email sent to [email protected]
