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

Re: Inheritance...


  • Subject: Re: Inheritance...
  • From: Florijan Stamenkovic <email@hidden>
  • Date: Fri, 09 May 2008 11:49:16 -0400

Something that does it all in one place (root of the hierarchy)... Should take care of the problem with intermediate classes. It also fails quickly, as a reminder if one adds new subclasses to the hierarchy, but forgets to deal with their type identifiers.

private static final Map<String, Integer> mdSubtypes =
		new HashMap<String, Integer>();

	static{
		mdSubtypes.put(Asset.ENTITY_NAME, 2);
		mdSubtypes.put(BankAccount.ENTITY_NAME, 4);	//	subclass of Asset
		mdSubtypes.put(Cash.ENTITY_NAME, 3);			//	subclass of Asset
		mdSubtypes.put(Expense.ENTITY_NAME, 1);
	}

	public void awakeFromInsertion(EOEditingContext ec){
		super.awakeFromInsertion(ec);

		//	set the MD type
		Integer mdType = mdSubtypes.get(entityName());
		if(mdType == null) throw new IllegalStateException(
				"IDs not provided for subentity: "+entityName());
		setMdType(mdType);
	}


I'm still concerned that you aren't checking it to see if it is null before setting it... According to the Apple documentation: http://developer.apple.com/documentation/WebObjects/ Enterprise_Objects/BusinessLogic/chapter_4_section_3.html "Determining if the attribute is null is not usually necessary except in three-tier Java Client applications."

Interesting, I never saw that... As for checking on null, sorry, forgot to mention that JBND does that for me (or, to be more precise, checks if the value being set is equal to the value currently had, for attributes, and if so, it ignores the setting call)


:P

Now, they don't explain why it's important for JC, but I _think_ the client-side EditingContext acts something like a nested EC to the server EC, so when you copy the client-side EC back to the server, the EO is getting "inserted" again into the server-side EC, and _I believe_ awakeFromInsertion gets called on the server again. If you've already set the value of the attribute on the client (and not necessarily to
what awakeFromInsertion will set) then when it shows up on the server, it gets overridden by the server-side awakeFromInsertion. Yuck.

Yuck, and urgh.... Sounds fishy though, we need to verify this. I will check it out.


As far as the weirdness goes, other than values getting overridden unintentionally, the problems that I ran into were errors with the Undo Manager any time I tried to delete an instance of a class that had awakeFromInsertion called without first checking if the value was null.

<feelingVeryGood> I don't do NSUndoManager </feelingVeryGood>

I consider it a JC best-practice to always have the awakeFromInsertion methods match on the client and server...

Well, this applies if you are doing server-side work. I try to avoid that. However in principle I agree with the philosophy. It's just a pain to maintain.


Any new instances that were created on the server will then be copied down to the client, and _I think_ get awakeFromInsertion called on them again.

No, this does not happen. Once an EO is saved, I awakeFromInsertion doesn't get called on it when fetched to the client. I am not sure about the scenario you mention above, but of this I am. Actually, I think that once an EO is saved, awakeFromInsertion never gets called on it again, anywhere.


Now, If I had a common class that both the Server and Client classes extended I'd put it there so I wouldn't have duplicate code, but until Mike gets off his lazy butt and finishes adding support for a common parent class to EntityModeler and Veogen I have to put the same awakeFromInsertion call on both sides. ;-)

I am worried about integrating JBND with this. Since all JBND used EOs need to implement the DataObject interface. The easiest way is to make them inherit EOFDataObject, but this is client side only class, meaning: bye-bye common EO code. I need to figure out a way to solve this.


F
_______________________________________________
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


References: 
 >Inheritance... (From: Florijan Stamenkovic <email@hidden>)
 >Re: Inheritance... (From: Chuck Hill <email@hidden>)
 >Re: Inheritance... (From: Mike Schrag <email@hidden>)
 >Re: Inheritance... (From: Florijan Stamenkovic <email@hidden>)
 >Re: Inheritance... (From: Florijan Stamenkovic <email@hidden>)
 >Re: Inheritance... (From: Ken Anderson <email@hidden>)
 >Re: Inheritance... (From: Florijan Stamenkovic <email@hidden>)
 >Re: Inheritance... (From: Mike Schrag <email@hidden>)
 >Re: Inheritance... (From: Florijan Stamenkovic <email@hidden>)
 >Re: Inheritance... (From: David Avendasora <email@hidden>)
 >Re: Inheritance... (From: David Avendasora <email@hidden>)
 >Re: Inheritance... (From: Florijan Stamenkovic <email@hidden>)
 >Re: Inheritance... (From: David Avendasora <email@hidden>)

  • Prev by Date: Re: WO Tutorials install on windows
  • Next by Date: Re: Returning a PDF from a long response page
  • Previous by thread: Re: Inheritance...
  • Next by thread: Re: Inheritance...
  • Index(es):
    • Date
    • Thread