Re: limiting All Queries in D2W
Re: limiting All Queries in D2W
- Subject: Re: limiting All Queries in D2W
- From: Fabian Peters <email@hidden>
- Date: Fri, 30 Jan 2015 15:45:25 +0100
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@hidden> 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@hidden>:
>>
>>> 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@hidden> 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@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden