• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Filtering an array of EO objects in D2J (getting the data source)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Filtering an array of EO objects in D2J (getting the data source)


  • Subject: Re: Filtering an array of EO objects in D2J (getting the data source)
  • From: Ricardo Strausz <email@hidden>
  • Date: Mon, 12 Jan 2004 18:59:57 -0600

Hola Ray!

One posibility (not very efficient, but ease to implement) is the following; suppose we have a master-->>detail relation and, once selected a masterObject, we want only those details related to master which ALSO have the atribute toFilter>0.

So, by default, the detailDisplayGroup will fetch all details with FK = masterObject.PK but if we set a qulifier to such a displayGroup we can get the filtered array with displayedObjects() (instead of allObjects()):

detailDisplayGroup.setQualifier(new
   EOQualifier.qualifierWithQualifierFormat("toFilter>0",null));
filteredArray = detailDisplayGroup.displayedObjects();

Observe that it is different from

displayGroup.dataSource().setQualifier...
array = displayGroup.allObjects();

The problem is that, eventhough the displayGroup is qualified, it will retrive ALL related objects from the db and show/display ONLY those that match the qualifier; so, if the displayGroup's qualifier is realy restrictive, there can be a time/resources-consumming isue.

When you find a better approach, please let us know.

Yours,
Dino


On Nov 30, 2003, at 4:59, Ray Ackland wrote:

JP, just for your information, I'm still working on this filtering thing. It is like the proverbial maze, where you go down one passage after another discovering that each one is a dead end - or leads you back to the start.

It is wearing me out, but I am still enjoying discovering all these little pieces of the puzzle.

At this stage I have discovered that you can only set an auxiliary qualifier on an EODatabaseDataSource (or EODistributedDataSource) but I now realise I am working with a EODetailDataSource.

I have also discovered the EODataSourceFactory, but its method to set the auxiliary qualifier also didn't work.

It's really weird - it's like there is no way to put an additional qualifier on a detail data source, yet if I add a qualifier statically to the EOModel it works just how I want it to. If I could only figure out how to do it programmatically. I am now looking at subclassing EODetailDataSource to see if I can do anything there.

Ray.

PS I also found that the data source appeared the next time I went into the relevant view. It was creating it at the stage of getting the data, and kept the same source for future objects. So I could probably just create my own as you mention, but this doesn't look like it will be of any help unless I can figure out this auxiliary qualifier in any case.


On 29/11/2003, at 23:16, Jean Pierre Malrieu wrote:

Ray,

If you can't solve your dataSource problem (but you probably will), you can build your editingContext and dataSource yourself.
Write a (or several) provider method in your controller class, and write a rule setting the provider method.


JP.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: Re: Limiting number of assignments in a many-to-many relationship
  • Next by Date: Re: Limiting number of assignments in a many-to-many relationship
  • Previous by thread: Re: handles requests concurrently: problems
  • Next by thread: EOModeling qualified one to many
  • Index(es):
    • Date
    • Thread