Re: EOGenerator Relationships
Hi Michael,
Try putting an @Override flag on the line before this method. If you
really aren't overriding it, this will cause the method to throw a
compiler error.
If it doesn't complain, it means that the code calling this method is
calling the _Invoice version of the method directly somehow.
When you created the instance you are now trying to update, did you
insert it into an editing context?
Dave
On Sep 16, 2008, at 7:23 PM, Michael Kondratov wrote:
I am having the strangest problem. I am unable to override set
relationship methods.
Example:
public void setInvoiceStatusRelationship(InvoiceStatus value) {
System.out.println(updating invoice status);
if(value != invoiceStatus()) {
System.out.println(updating invoice status date);
this.setInvoiceStatusDate(new NSTimestamp());
}
super.setInvoiceStatusRelationship(value);
}
But it is never called. Instead a method
setInvoiceStatusRelationship(value) from _Invoice (EOGenerator file)
is being called.
Any advise?
Michael Kondratov
Aspire Auctions, Inc.
www.aspireauctions.com
216-231-5515
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
On Sep 17, 2008, at 06:18, David Avendasora wrote: If it doesn't complain, it means that the code calling this method is calling the _Invoice version of the method directly somehow. I believe it is possible to do this using reflection. It however should not be happening, unless you are purposely doing it. It sounds like your inheritance tree is not what it should be (Invoice does not subclass _Invoice). Or the method signature differs (the _Invoice method takes an argument of a different type). Be sure to check that out first. Like Dave said, @Override is a fast way to address that. Or, you are actually dealing with an instance of _Invoice, and not of Invoice. Which would be weird, but possible I guess. In that case all of the above would check out, but you'd still be calling the _Invoice method. When you created the instance you are now trying to update, did you insert it into an editing context? What's your point Dave? I don't see how this would influence the runtime binding of methods. F ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
On Sep 17, 2008, at 9:56 AM, Florijan Stamenkovic wrote:
When you created the instance you are now trying to update, did you
insert it into an editing context?
What's your point Dave? I don't see how this would influence the
runtime binding of methods.
I've seen weird things happen if you try to do things to an object
without first inserting it into an EditingContext. Things that seem
totally unrelated to EOF. While I doubt it is actually the problem it
was the first thing that popped into my mind when you are getting
unexpected results from something as simple as this.
The other related thing I would ask is: Where are you calling this
method from? You aren't calling it from a constructor, are you?
This is the type of method I would expect that you would want to call
when creating an Invoice for the first time to setup default values.
For example, set it's status to Open or something.
If you are calling this method as part of first creating an invoice,
make sure you are doing it from awakeFromInsertion instead of the
constructor.
Unrelated, but also something to consider: What behavior do you expect
when the InvoiceStatus is set to null? (EOF does this when you delete
an invoice) Should it update the InvoiceStatusDate value then? If not
then you're if-statement should also check to be sure that the passed
value is not null.
if(value != null value != invoiceStatus()) {
Dave ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
It sounds like your inheritance tree is not what it should be (Invoice does not subclass _Invoice). I'm 100% with Florijan here. You're confusing your classes somehow and putting that method in the wrong place. You couldn't end up with an actual _Invoice because those _Classes (at least in all the templates I ship in WOL) are abstract, so you have the overridden method in the wrong place. ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
The object is in the EC.
I've tried changing Invoice method from
setInvoiceStatusRelationship(InvoiceStatus value) to
setInvoiceStatus(InvoiceStatus value)
Now setInvoiceStatus in Invoice does get exceuted, however I am not
able to call super.setInvoiceStatusRelationship(value) because they
start calling each other!!
Michael
On Sep 17, 2008, at 10:18 AM, David Avendasora wrote:
On Sep 17, 2008, at 9:56 AM, Florijan Stamenkovic wrote:
When you created the instance you are now trying to update, did
you insert it into an editing context?
What's your point Dave? I don't see how this would influence the
runtime binding of methods.
I've seen weird things happen if you try to do things to an object
without first inserting it into an EditingContext. Things that seem
totally unrelated to EOF. While I doubt it is actually the problem
it was the first thing that popped into my mind when you are getting
unexpected results from something as simple as this.
The other related thing I would ask is: Where are you calling this
method from? You aren't calling it from a constructor, are you?
This is the type of method I would expect that you would want to
call when creating an Invoice for the first time to setup default
values. For example, set it's status to Open or something.
If you are calling this method as part of first creating an invoice,
make sure you are doing it from awakeFromInsertion instead of the
constructor.
Unrelated, but also something to consider: What behavior do you
expect when the InvoiceStatus is set to null? (EOF does this when
you delete an invoice) Should it update the InvoiceStatusDate value
then? If not then you're if-statement should also check to be sure
that the passed value is not null.
if(value != null value != invoiceStatus()) {
Dave
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauctions.com
This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
Hmmm... Well this is my _Invoice class:
// $LastChangedRevision: 5074 $ DO NOT EDIT. Make changes to
Invoice.java instead.
package auction;
import com.webobjects.eoaccess.*;
import com.webobjects.eocontrol.*;
import com.webobjects.foundation.*;
import java.math.*;
import java.util.*;
import org.apache.log4j.Logger;
@SuppressWarnings(all)
public abstract class _Invoice extends EOGenericRecord {
public static final String ENTITY_NAME = Invoice;
// Attributes
public static final String CREATED_ON_KEY = createdOn;
public static final String HIDDEN_NOTE_KEY = hiddenNote;
...
It was created by EOGenerator.
This is my Invoice class:
package auction;
// Invoice.java
// Created on Fri Feb 28 17:04:21 US/Eastern 2003 by Apple EOModeler
Version 5.0
import java.math.BigDecimal;
import com.webobjects.eoaccess.EOUtilities;
import com.webobjects.eocontrol.EOEditingContext;
import com.webobjects.eocontrol.EOSortOrdering;
import com.webobjects.foundation.NSArray;
import com.webobjects.foundation.NSMutableArray;
import com.webobjects.foundation.NSMutableDictionary;
import com.webobjects.foundation.NSTimestamp;
import org.apache.log4j.Logger;
public class Invoice extends auction._Invoice {
@SuppressWarnings(unused)
private static Logger log = Logger.getLogger(Invoice.class);
public BigDecimal salesTax() {
...
I am at a complete loss.
Michael
On Sep 17, 2008, at 10:56 AM, Mike Schrag wrote:
It sounds like your inheritance tree is not what it should be
(Invoice does not subclass _Invoice).
I'm 100% with Florijan here. You're confusing your classes somehow
and putting that method in the wrong place. You couldn't end up
with an actual _Invoice because those _Classes (at least in all the
templates I ship in WOL) are abstract, so you have the overridden
method in the wrong place.
ms
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauctions.com
This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
I've tried changing Invoice method from setInvoiceStatusRelationship(InvoiceStatus value) to setInvoiceStatus(InvoiceStatus value) Now setInvoiceStatus in Invoice does get exceuted, however I am not able to call super.setInvoiceStatusRelationship(value) because they start calling each other!! If you're not using Wonder's automatic inverse relationship stuff, then depending on how you bind this value, it will effect what gets called. the setXxxRelationship methods add to both sides of relationship with key. They are not, however, called if you just bind these values to a form element (like a WOPopUpButton selection binding). If you want to catch that, you need to override setInvoiceStatus. You should never call super.setXxxRelationship from setXxx, though, or you're just asking for infinite loops. You should be able to override setXxx and call super.setXxx at the end ONLY and not override the setXxxRelationship method, but it's been a while since I've had automatic inverse relationship stuff turned off, so YMMV. ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
this is what I've tried:
public void setInvoiceStatus(InvoiceStatus value) {
System.out.println(updating invoice status);
if(value != invoiceStatus()) {
System.out.println(updating invoice status date);
this.setInvoiceStatusDate(new NSTimestamp());
}
super.setInvoiceStatusRelationship(value);
}
setInvoiceStatus does get called. Having
super.setInvoiceStatusRelationship(value) causes an infinite loop. If
I remove super.setInvoiceStatusRelationship(value); then relationship
is never updated.
Michael
On Sep 17, 2008, at 11:11 AM, Mike Schrag wrote:
I've tried changing Invoice method from
setInvoiceStatusRelationship(InvoiceStatus value) to
setInvoiceStatus(InvoiceStatus value)
Now setInvoiceStatus in Invoice does get exceuted, however I am not
able to call super.setInvoiceStatusRelationship(value) because they
start calling each other!!
If you're not using Wonder's automatic inverse relationship stuff,
then depending on how you bind this value, it will effect what gets
called. the setXxxRelationship methods add to both sides of
relationship with key. They are not, however, called if you just
bind these values to a form element (like a WOPopUpButton selection
binding). If you want to catch that, you need to override
setInvoiceStatus. You should never call super.setXxxRelationship
from setXxx, though, or you're just asking for infinite loops. You
should be able to override setXxx and call super.setXxx at the end
ONLY and not override the setXxxRelationship method, but it's been a
while since I've had automatic inverse relationship stuff turned
off, so YMMV.
ms
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauctions.com
This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
Wonder's automatic inverse relationship stuff What's that? Mind explaining briefly, or pointing out where it is in wonder? call super.setXxx As far as I can see your _Entity (http://webobjects.mdimension.com/ wolips/EOGenerator/Velocity%20EOGenerator%20Templates/_Entity.java) does not have setXxx(...) for relationships. So, why is that? F ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
takeStoredValueForKey(value, INVOICE_STATUS_KEY); or super.setInvoiceStatus(...) (NOT the relationship one) which does pretty much this ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
I've added takeStoredValueForKey(value, INVOICE_STATUS_KEY); and now
it works! Thank you so much. I was totally confused.
Michael
Aspire Auctions
216-231-5515
www.aspireauctions.com
On Sep 17, 2008, at 11:26 AM, Florijan Stamenkovic wrote:
On Sep 17, 2008, at 10:56, Michael Kondratov wrote:
The object is in the EC.
I've tried changing Invoice method from
setInvoiceStatusRelationship(InvoiceStatus value) to
setInvoiceStatus(InvoiceStatus value)
Now setInvoiceStatus in Invoice does get exceuted, however I am not
able to call super.setInvoiceStatusRelationship(value) because they
start calling each other!!
That's because setInvoiceStatusRelationship(value) calls
addObjectToBothSidesOfRelationship(...) which in turn calls
setInvoiceStatus(value).
You need to get into how WO's key value coding works. Check out the
documentation for EOCustomObject, specifically these methods:
addObjectToBothSidesOfRelationship
takeValueForKey
takeStoredValueForKey
As for your problem, from what I understand you are trying to
achieve, you should override setInvoiceStatus(value) in your Invoice
class to do the extra work. Your method should look like this:
public void setInvoiceStatus(InvoiceStatus value) {
if(value != invoiceStatus()) {
System.out.println(updating invoice status date);
this.setInvoiceStatusDate(new NSTimestamp());
takeStoredValueForKey(value, INVOICE_STATUS_KEY);
}
}
You calling code should however use
setInvoiceStatusRelationship(...) to reap it's benefits, which will
in turn call your setInvoiceStatus(...) method. Also note that the
first line in that method only applies if the two InvoiceStatus EOs
are in the same EC.
F
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
Wonder's automatic inverse relationship stuff What's that? Mind explaining briefly, or pointing out where it is in wonder? On ERXGenericRecord: * Also, this class supports auto-updating of inverse relationships. You can * simply call codeeo.setFoo(other), eo.takeValueForKey(other), * eo.addObjectToBothSidesOfRelationshipWithKey(other, foo)/code * or codeeo.addToFoos(other)/code and the inverse relationship will get * updated for you automagically, so that you don't need to call * codeother.addToBars(eo)/code or codeother.setBar(eo)/code. Doing * so doesn't hurt, though. Giving a codenull/code value of removing the * object from a to-many will result in the inverse relationship getting * cleared. br / * If you *do* call addToBars(), you need to use * includeObjectIntoPropertyWithKey() in this method.br * This feature should greatly help readability and reduce the number errors you * make when you forget to update an inverse relationship. To turn this feature * on, you must set the system default * code er.extensions.ERXEnterpriseObject.updateInverseRelationships=true/ code. The _Wonder.java templates check for this and can function in both scenarios properly. What this basically addresses are for things like where you bind a WOPopUpButton selection to a to-one relationship. All that does is set one side of the relationship, which is terribly confusing for people. This setting makes it so inverse relationships are always updated. There was a great debate about this a few months ago, actually ... You can search the archives for it. call super.setXxx As far as I can see your _Entity (http://webobjects.mdimension.com/wolips/EOGenerator/Velocity%20EOGenerator%20Templates/_Entity.java ) does not have setXxx(...) for relationships. So, why is that? I don't think you actually need them ... EOF will do the right thing in the absence of the non-XxxRelationship set methods. That said, I don't actually use those templates -- I use _Wonder.java, but the addition of the setXxx methods I think is pretty recent (I think I only added them when I fixed automatic inverse relationship updating). ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
There is no setInvoiceStatus in _Invoice. Only setInvoiceStatusRelationship. Now, I assume that _Invoice.setInvoiceStatusRelationship gets called first and in turn calls Invoice.setInvoiceStatus . Is that correct? On Sep 17, 2008, at 11:35 AM, Mike Schrag wrote: takeStoredValueForKey(value, INVOICE_STATUS_KEY); or super.setInvoiceStatus(...) (NOT the relationship one) which does pretty much this ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauctions.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
On Sep 17, 2008, at 12:02, Michael Kondratov wrote: There is no setInvoiceStatus in _Invoice. Only setInvoiceStatusRelationship. See what Mike was just saying... Now, I assume that _Invoice.setInvoiceStatusRelationship gets called first and in turn calls Invoice.setInvoiceStatus . Is that correct? Yes, the stack trace would look like this: EOCustomObject.takeStoredValueForKey(value, invoiceStatus) Invoice.setInvoiceStatus(value) EOCustomObject.takeValueForKey(value, invoiceStatus) EOCustomObject.addObjectToBothSidesOfRelationshipWithKey(value, invoiceStatus) _Invoice.setInvoiceStatusRelationship(value) F ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EOGenerator Relationships
On 17.09.08 10:02, Michael Kondratov [EMAIL PROTECTED] wrote: There is no setInvoiceStatus in _Invoice. Only setInvoiceStatusRelationship. Then you are using either a very old WOLips or some old templates. cug ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
