You know, I’m about the last one to be talking about hidden code, I’ve taken to putting all kinds of stuff in the EOModel’s userInfo dictionaries that in-conjunction with my EOGen templates put all kinds of coolness in my _Entity classes.
The end result is easily visible, but how the heck it got there… totally obtuse. Gotta work on that! Dave On Dec 5, 2013, at 2:52 PM, Hugi Thordarson <h...@karlmenn.is> wrote: > Hi David! > I don’t like surprises either (unless they’re being handed out by scantily > clad censored my girlfriend)—that’s why I have the interfaces. For any > modification to take place, the EOs must explicitly implement the interfaces > to get the desired functionality (TimeStamped and UserStamped) so from the > viewpoint of the developer nothing unexpected is happening. It’s really just > shorthand for putting I’d usually put in good ol’ awakeFromInsertion. > > Current implementation: > https://bitbucket.org/hugi/soloweb/src/622c9e83b527d9d4907be0e529fa81deddc21fa6/Sources/concept/managers/TransactionStamper.java?at=master > > Cheers, > - hugi > > > > > On 5.12.2013, at 17:45, David Avendasora <webobje...@avendasora.com> wrote: > >> 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 <h...@karlmenn.is> 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 <bogdan.zlata...@gmail.com> 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 <h...@karlmenn.is> 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 <j...@oyosys.de> 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 <h...@karlmenn.is>: >>>>>> >>>>>>> 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 (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/bogdan.zlatanov%40gmail.com >>>>> >>>>> This email sent to bogdan.zlata...@gmail.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: >>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >>> >>> This email sent to webobje...@avendasora.com >> >> >> ————————————————————————————— >> WebObjects - so easy that even Dave Avendasora can do it!™ >> ————————————————————————————— >> David Avendasora >> Senior Software Abuser >> Nekesto, Inc. >> >> >> >> >> > > > > Begin forwarded message: > >> From: David Avendasora <webobje...@avendasora.com> >> Subject: Re: processRecentChanges makes me sad >> Date: 5. desember 2013 17:45:39 GMT >> To: Hugi Þórðarson <h...@karlmenn.is> >> Cc: WebObjects-Dev Mailing List List <webobjects-dev@lists.apple.com> >> >> 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 <h...@karlmenn.is> 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 <bogdan.zlata...@gmail.com> 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 <h...@karlmenn.is> 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 <j...@oyosys.de> 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 <h...@karlmenn.is>: >>>>>> >>>>>>> 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 (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/bogdan.zlatanov%40gmail.com >>>>> >>>>> This email sent to bogdan.zlata...@gmail.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: >>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >>> >>> This email sent to webobje...@avendasora.com >> >> >> ————————————————————————————— >> WebObjects - so easy that even Dave Avendasora can do it!™ >> ————————————————————————————— >> David Avendasora >> Senior Software Abuser >> Nekesto, Inc. >> >> >> >> >> ————————————————————————————— 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
