Hey Hugi! Using notifications to add “boilerplate" functionality without needing to directly modify the EO, some superclass of the EO (via template changes, or a CustomGenericRecord) or extending the EditingContext certainly is flexible and keeps you all nicely loosely-coupled. And we all know how you like your loose coupling.
There is a downside, however. When you are doing something fundamental like setting attributes that are meaningful to the user - especially in a framework for wider distribution - it can make the learning curve much steeper for developers wanting to make use of it. I’m not saying that it is wrong, just that there is a downside to being so dynamic. Showing a user one value (or no value) then setting it later, violates the principle of “least surprise”. Personally, I’d lean towards somehow coming up with the value at insertion, or pre-save so you can show it to the user, even if it is not exactly accurate in terms of when the object was actually persisted. But, every app’s requirements are different! What is cool is that WO gives you so many ways to hang yourse… er… I mean… gives you so many options of how to handle these types of things! Dave On Dec 4, 2013, at 6:57 AM, 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/webobjects%40avendasora.com > > This email sent to [email protected] ————————————————————————————— WebObjects - so easy that even Dave Avendasora can do it!™ ————————————————————————————— David Avendasora Senior Software Abuser Nekesto, Inc.
_______________________________________________ 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]
