BTW here is the method that is called when you click the New button:
/**
* Performs the newObjectAction. Creates a new object and sets the
inline task
* to 'create'
*/
public WOComponent newObjectAction() {
EOEditingContext newEc =
ERXEC.newEditingContext(masterObject().editingContext());
EOClassDescription relatedObjectClassDescription =
masterObject().classDescriptionForDestinationKey(relationshipKey());
EOEnterpriseObject relatedObject =
(EOEnterpriseObject)EOUtilities.createAndInsertInstance(newEc,
relatedObjectClassDescription.entityName());
EOEnterpriseObject localObj =
EOUtilities.localInstanceOfObject(relatedObject.editingContext(),
masterObject());
if (localObj instanceof ERXGenericRecord) {
((ERXGenericRecord)localObj).setValidatedWhenNested(false);
}
localObj.addObjectToBothSidesOfRelationshipWithKey(relatedObject,
relationshipKey());
setSelectedObject(relatedObject);
setInlineTaskSafely("create");
return null;
}
What is interesting is that the masterObject() is the Person EO.
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]
