It is not necessary to put all the java files at the top level of the project. The requirement is actually that the .eomodeld files must be in the same directory as the custom EO class files. As long as you do this, the merge option will work fine. Having said all this I realize that most people are using EOGenerator for generating their class files. But just wanted to clear up a few things on this issue. For anyone interested in using EOModeler for generating class files instead of EOGenerator; I would recommend modifying the templates that EOModeler uses to generate the files. I modified mine to insert comments between each of the repeating sections and added a comment at the end where the custom business logic will be inserted. It seems to work best to put all your custom logic at the end of the file (after all the auto generated stuff). This really cuts down on merge conflicts. In most cases all your changes are wrapped within a single difference in FileMerge just pick that up and you're good to go. The comments help prevent FileMerge from getting confused. Here's an example: ... ... /* * Class attributes */ public String orderNumber() { return (String)storedValueForKey("orderNumber"); } public void setOrderNumber(String value) { takeStoredValueForKey(value, "orderNumber"); } /* * To-one relationships */ public Customer customer() { return (Customer)storedValueForKey("customer"); } public void setCustomer(Customer value) { takeStoredValueForKey(value, "customer"); } /* * To-many relationships */ public NSArray items() { return (NSArray)storedValueForKey("items"); } public void setItems(NSArray value) { takeStoredValueForKey(value, "items"); } public void addToItems(Item object) { includeObjectIntoPropertyWithKey(object, "items"); } public void removeFromItems(Item object) { excludeObjectFromPropertyWithKey(object, "items"); } /* * Custom business logic */ /* Insert custom business logic here */ ... ... Question for EOGenerator experts: Is it possible to use EOGenerator for building class files that use the "Business Logic Partitioning" recommendation explained in "WebObjects Java Client Programming Guide." This is the pattern that uses three Java packages where "common" includes class files that can be used on either side or abstract superclass for entities that need to have differences on the "server" and "client" sides? I've never been able to figure out any way to accomplish this with EOGenerator (and it's not that straight forward to do with EOModeler either). What I do is generate a new copy of the class file then cut-and-paste the accessor methods into the class within the "common" package. On May 10, 2006, at 9:16 AM, Randy Wigginton wrote:
-- Robert Walker |
_______________________________________________ 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]
