• 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: EOModeler
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOModeler


  • Subject: Re: EOModeler
  • From: Arturo Pérez <email@hidden>
  • Date: Sun, 11 Jan 2004 23:27:21 -0500

On Jan 11, 2004, at 10:24 PM, james cicenia wrote:

Arturo,

I do understand what you are suggesting. But wouldn't it just be quicker
and easier to use the database for this? In other words, my graph object
would just issues a simple, for example:


Select count(department) from project_request
where status=open group by department.

And then just turn this simple result into a list which would be part
of my graph object?

-James


I seem incapable of crafting a response that won't seem condescending or that won't irritate you further. So just let me leave it at.

Sure. You can do that. The database IS good at that sort of thing. But it's
the wrong approach.



On Jan 11, 2004, at 9:11 PM, Arturo Pirez wrote:


On Jan 11, 2004, at 9:55 PM, james cicenia wrote:

What collection of your objects would benefit by being grouped?

The groupings would be for graphing. For instance the count of all open project requests
by department.

That's a reporting use of WO. Not my forte. When faced with that sort of thing I would do
the following.


Assumption: There are Department objects and Project objects. There is a relationship
between them so one can say department.allProjects() that is a one-to-many (one department
can have many projects). Project objects have a status field with values: open, closed, cancelled.


So, I would write a fetch spec on Department that looks something like
department->allProjects->status == open
and I would have a list of departments with open projects. At this point there are two strategies.
One is to write in the WOComponent an EOQualifier.filteredArray... to get the open projects for
each department. Alternatively you could add to the Department.java a method called openProjects()
that does the filtering. Either way you'll end up with an NSArray of projects with status == open
(call it openProjectsNSArray).


In that case you bind to a WOString
	openProjectsNSArray.@count

Notice above that the fetch spec is on Department not Project. This is because you're paginating
your report by Department. Otherwise you'd have to find all open projects and then "slice" the
resulting array into departmental subsets which feels more cumbersome to me.


Does that all make sense to you?
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.




--arturo
_______________________________________________
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.

  • Follow-Ups:
    • Re: EOModeler
      • From: james cicenia <email@hidden>
References: 
 >EOModeler (From: james cicenia <email@hidden>)
 >Re: EOModeler (From: Arturo Pérez <email@hidden>)
 >Re: EOModeler (From: james cicenia <email@hidden>)
 >Re: EOModeler (From: Arturo Pérez <email@hidden>)
 >Re: EOModeler (From: james cicenia <email@hidden>)

  • Prev by Date: Re: EOModeler and more
  • Next by Date: Re: EOModeler and more
  • Previous by thread: Re: EOModeler
  • Next by thread: Re: EOModeler
  • Index(es):
    • Date
    • Thread