Those methods may get called too early. I'd suggest you just write a method that returns the relationship candidates. When that method is being called and a person is still not set, then we'll have another look.
Fabian Am 30.01.2015 um 16:01 schrieb Theodore Petrosky <[email protected]>: > actually I am looking at that now. I created in my BookPerson EO: > > @Override > public void awakeFromInsertion(EOEditingContext editingContext) { > // TODO Auto-generated method stub > super.awakeFromInsertion(editingContext); > > System.out.println("awakeFromInsertion person: “+ person()); > } > > in the log: > awakeFromInsertion person: null > > in the init method: > System.out.println("creating a new bookperson person: "+ person()); > > in the log: > creating a new bookperson person: null > > I thought that when the BookPerson EO was created it would be assigned the > person. > > I was thinking of storing it on the session but I didn’t think of > session.objectStore. I was thinking of using thread storage. > > But where would you do this? > > > > > > On Jan 30, 2015, at 9:45 AM, Fabian Peters <[email protected]> wrote: > >> Well, I'm not sure about your model, but: If editing a Person and clicking >> on the book relations "new" button, I would expect the created Book object >> to have its "person" relationship be set to the person EO you're editing. >> >> If the EO is inaccessible, then you can alway resort to storing it on the >> session, e.g. in "session.objectStore". >> >> Fabian >> >>> Ok, maybe using the restrictedChoiceKey option and put a method on the EO >>> that returns an array of these objects. >>> >>> But how do I pass in either the Person EO that I am editing, or an array of >>> (in this case) “Person.Shows" that are assigned to this Person? >>> >>> Obviously, if I can pass in the Person, I can create a Qualifier based on >>> that Person. >>> >>> Book.(<theShowsForThisPerson>) and >>> Book.INSTRUMENT.eq(<theInstrumentForThisPerson>) >>> >>> I need to add a qualifier to this method to return a subset based on the >>> parent object’s instrument and shows. >>> >>> Ted >>> >>> >>> >>> On Jan 30, 2015, at 2:37 AM, Fabian Peters <[email protected]> wrote: >>> >>>> Hi Ted, >>>> >>>> The most basic rule would be: >>>> >>>> 100 : entity.name like '*' => queryDataSourceDelegate = >>>> "COM.YOUR-PACKAGE.LimitBooksToPersonDataSourceDelegate" >>>> [ERDDelayedObjectCreationAssignment] >>>> >>>> But if you want to limit the choices in a relationship component, the >>>> "restrictedChoiceKey" approach should be easier to use: >>>> >>>> 100 : (task = 'edit' and entity.name = 'Location' and propertyKey = >>>> 'parentLocation') => restrictedChoiceKey = >>>> "object.availableParentLocations" [com.webobjects.directtoweb.Assignment] >>>> >>>> Just put a method on the EO that returns the possible choices for the >>>> relationship. >>>> >>>> HTH, Fabian >>>> >>>> Am 29.01.2015 um 16:41 schrieb Theodore Petrosky <[email protected]>: >>>> >>>>> Fabian, >>>>> >>>>> You commented on this a long time ago. and in checking my old emails, I >>>>> see this is along the lines of what I need. >>>>> >>>>> I have a D2W app with an embedded toMany CreateEmbeddedBookPerson that >>>>> has an ERD2WEditToOneRelationship that I am trying to create a fetch >>>>> specification for. >>>>> >>>>> I see in the logs: >>>>> >>>>> DEBUG NSLog Page: er.modern.look.pages.ERMODInspectPage - Configuration: >>>>> EditPerson Page: er.modern.look.pages.ERMODEditRelationshipPage - >>>>> Configuration: EditRelationshipEmbeddedBookPerson >>>>> (CreateEmbeddedBookPerson) - evaluateExpression: >>>>> <com.webobjects.jdbcadaptor.PostgresqlExpression: "SELECT t0.booktitle, >>>>> t0.eventid, t0.id, t0.instrumentfamilyid, t0.showid FROM book t0" >>>>> withBindings: > >>>>> Jan 29 10:26:28 Booking_D2W[61840] DEBUG NSLog Page: >>>>> er.modern.look.pages.ERMODInspectPage - Configuration: EditPerson Page: >>>>> er.modern.look.pages.ERMODEditRelationshipPage - Configuration: >>>>> EditRelationshipEmbeddedBookPerson (CreateEmbeddedBookPerson) - 29 row(s) >>>>> processed >>>>> >>>>> There we have it. it is getting 29 rows. If I create: >>>>> >>>>> public class LimitBooksToPersonDataSourceDelegate extends >>>>> EODatabaseDataSource implements ERDQueryDataSourceDelegateInterface { >>>>> >>>>> add the required methods and add in some sys logs to see if it gets >>>>> fired. But what is the rule? Am I barking up the wrong tree? >>>>> >>>>> A little help would be appreciated! >>>>> >>>>> >>>>> On Apr 13, 2012, at 9:27 AM, Fabian Peters <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> Am 13.04.2012 um 11:34 schrieb Theodore Petrosky: >>>>>> >>>>>>> I don't even know where to begin. I have a D2W app that manages Briefs. >>>>>>> A Brief is created by a User. (one to one relation) >>>>>>> >>>>>>> I can easily create a tab that calls a method to limit the resultant >>>>>>> list to only those Briefs created by the current User. However, where >>>>>>> do I 'fix' the search area. >>>>>>> >>>>>>> I mean if the current User is Sally, she will search for Brief(s) that >>>>>>> the Objective attribute contains the word 'Iceman'. But I want all >>>>>>> queries to include 'and user = 'Sally'. >>>>>> >>>>>> You can add restricting qualifiers (almost) globally via >>>>>> "editingContextShouldFetchObjects" in ERXEditingContextDelegate. Just >>>>>> create your own EC delegate and use it to modify the fetch spec. To >>>>>> define your custom delegate as the default delegate: >>>>>> >>>>>> new ERXEC.DefaultFactory() >>>>>> .setDefaultEditingContextDelegate(new >>>>>> DREditingContextDelegate()); >>>>>> >>>>>>> Sally should not see Bob's Briefs. I am trying to embrace D2W, and (for >>>>>>> me) this would be trivial in a Wonder app. >>>>>> >>>>>> For D2W you can subclass EODatabaseDataSource and modify the >>>>>> constructors and the "setFetchSpecification" method to ensure >>>>>> restrictions are applied. To make sure your subclass gets used you can >>>>>> implement "ERDQueryDataSourceDelegateInterface" and set it via the >>>>>> rules. Using only the queryDataSourceDelegate may also be sufficient >>>>>> depending on your needs. >>>>>> >>>>>> cheers, Fabian >>>>>> >>>>>>> Is there a property for this? >>>>>>> >>>>>>> Ted >>>>>>> _______________________________________________ >>>>>>> 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/lists.fabian%40e-lumo.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]
