Hi Ramsey,

On Aug 29, 2011, at 7:59 AM, Ramsey Gurley wrote:

> Put a breakpoint in validationFailedWithException in ERD2WPage.  Unless 
> you've added something really custom, that's what collects the validation 
> exceptions.  It can swallow exceptions under certain circumstances that I'm 
> aware of, but haven't had time to fix it the way I would like yet.
> 
> Also, check your page template for the page that collects validation errors.  
> If you throw a validation exception, but you don't have any components on the 
> page to display them, it won't matter if ERD2WPage does the right thing or 
> not.

Good point. I was assuming (yea, I know) that all the ERMD stuff that could 
possibly trigger a saveChanges would have had the components to display 
validation exceptions. From a quick check, it appears that ERMODListPage does 
not. I'll look to see if I can add it in a way that makes sense.

> Also also, check the logic in ERMDDeleteButton.  There was a problem with 
> false deletes after validation failure in the old ERDDeletionDelegate.  If 
> ERMD uses similar logic, it likely suffers the same problem.

Shouldn't it use the _same_ logic, as in call the ERDDeletionDelegate? Why 
would we want the possibility of different delete handling logic depending upon 
which method of deletion you used?

In this case, it should revert the EC, but I understand that that is not going 
to always be the desired behavior for the button. Maybe I'll sublcass the 
component to make it a ERMDDeleteNowOrRevertButton, but that feels dirty. It 
should be a rule that defines the behavior on failure.

> More info available on this JIRA:
> 
> http://issues.objectstyle.org/jira/browse/WONDER-186

Okay. I looked through that, I'll see if it is something that can/should be 
applied here.

Thanks!

Dave

> 
> Ramsey
> 
> On Aug 28, 2011, at 3:57 PM, David Avendasora wrote:
> 
>> Hi all,
>> 
>> I've noticed a place where a validation error is swallowed by my D2W app. 
>> I'm not sure where the expetion is getting lost because ERMDDeleteButton 
>> catches it, and calls  but the error never shows up in the UI. The UI makes 
>> it look as though the delete was successful, but it wasn't.
>> 
>> The situation is this: I'm deleting an EO, but the EO has a toMany 
>> relationship with a deny delete rule. I'm overriding mightDelete() to move 
>> the related objects to a different EO. If the _destination_ EO is invalid 
>> (missing required data) then it fails validation (as it should) and the EC 
>> can't be saved.
>> 
>> For example, let's say I have students that are registered for a math class. 
>> That class is canceled, so all the students associated with it should be 
>> moved to the next available math class. The problem is that the math class 
>> that the students are moved to doesn't have a start time, which is a 
>> mandatory attribute (as defined by the EOModel). So when the EC is saved, 
>> the new math class is what fails validation.
>> 
>> So, the delete fails validation, not because the deletion itself fails 
>> validation, but because EOs involved in the background business logic end up 
>> failing validation. EOF is doing the right thing and preventing the save, 
>> but the UI is never reporting the validation error nor reverting the EC, so 
>> the UI ends up showing that the related objects have been moved to the new 
>> EO and the original EO is gone. If you simply create a new session and fetch 
>> the objects again, you see that they are all back to the way they were 
>> before the attempted deletion.
>> 
>> In this situation, once I figured out that there was an effectively 
>> "swallowed" validation exception, and then _which_ object was causing it, I 
>> was able to fix my model so that this didn't throw the exception anymore and 
>> everything is working fine. BUT, this exception should be displayed in the 
>> UI.
>> 
>> Dave
>> _______________________________________________
>> 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/ramseygurley%40gmail.com
>> 
>> This email sent to [email protected]
> 

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

Reply via email to