Hi, Jim & Chuck,
On Feb 16, 2006, at 9:11 PM, Chuck Hill wrote:
Hi Jim,
On Feb 16, 2006, at 5:36 PM, Jim Wong wrote:
oh... i have an entity COMPANY which has an attribute
customerIndustryID which stores for exception numbers like 7, 10,
11 etc. this numbers can be found in another entity INDUSTRY which
has a corresponding attribute like F&B (7), Banking (10),
Manufacturing (11) etc.
Now where is that Jerry Walker? He loves questions like this...
He was at choir practice rehearsing Mozart's Requiem. Wonderful music
and the right year to do it. :-)
...and you got some nerve, asking that, after traipsing around the
world for a month and making the rest of us work as hard as you do
answering these questions while you were gone!
OK, I will do a short version and Jerry can do the epic later.
I'm not sure there's any need for an epic here, if I understand Jim's
question correctly.
A fundamental rule of thumb with WO (and EOF in particular) is "If
you are thinking about keys, you are doing it wrong". Let EOF
worry about the numbers. You worry about objects.
What does your model look like? You should have a Company entity
related (the a to-one relationship) to an Industry entity based on
company.customer_industry_id = industry.industry_id or whatever you
called the columns in the database. If not, you should go back and
read the tutorials and documention on EOModeler and consider them
in the context of what you are trying to do.
Heh, yeah, what Chuck said.
How do I display all the information of a COMPANY in a form and
when it display customerIndustryID, i want it to display the name
like F&B, Banking, Manufacturing instead of the numbers stored in
the COMPANY?
First off, customerIndustryID should not be a class attribute so
you should not even have the option of showing it. :-) Exposed
keys Bad. Marking the primary and foreign keys as not class
properties (click the diamond to the left in EOModeler) can help
prevent many problems when you are starting out.
This is where I got a bit confused. If the Industry number is a
number assigned by some authoritative outside agency (say, a
government taxing agency or some such) and is meaningful to the users
of Jim's system as such, then it should probably be a class attribute
but it should NOT be used as a primary key for the industry table or
as a foreign key for the company table.
On the other hand, if it is simply an arbitrary (unique for each
industry) number that Jim made up, or that was assigned by his DBMS,
then Chuck is absolutely right, it is a primary key to the INDUSTRY
table, can be used as a foreign key in the COMPANY table, it is an
artifact of database technology and should not be carried over, or
show up at all, in Jim's object graph (that is, it should not be a
class property as Chuck mentioned).
So, Jim, if you were including the keys from the database in your
object graph, you're resisting the "Way of WO" and you're welcome to
request my epic answer. If not, then Chuck's answer (with no
admonitions) probably suffices.
Now, if your model is correct, all you need to do is to call
customer().industry().name() to get F&B, Banking etc. For use in
WO page, add a WOString and bind it to customer.industry.name.
Yes, it really is that simple when you are using WO!
Absolutely! I couldn't have said it better myself... I could have
said it in way more words, but not better. :-)
Regards,
Jerry
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
[EMAIL PROTECTED]
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
