Re: D2W Exception Handling
Re: D2W Exception Handling
- Subject: Re: D2W Exception Handling
- From: Fabian Peters <email@hidden>
- Date: Tue, 13 Mar 2012 22:04:32 +0100
Hi Ramsey,
Am 13.03.2012 um 18:20 schrieb Ramsey Gurley:
> On Mar 13, 2012, at 5:53 AM, Fabian Peters wrote:
>
>> Hi Ramsey,
>>
>> Am 13.03.2012 um 01:49 schrieb Ramsey Gurley:
>>
>>> On Mar 12, 2012, at 4:21 PM, Fabian Peters wrote:
>>>
>>>> Hi Ramsey,
>>>>
>>>>>> swallowed in ERD2WPage since d2wContext().propertyKey() is null. Setting the propertyKey from the exception resolves this:
>>>>>>
>>>>>> if (d2wContext().propertyKey() == null && erv.propertyKey() != null) {
>>>>>> d2wContext().setPropertyKey(erv.propertyKey());
>>>>>> }
>>>>>>
>>>>>> Maybe this (or some better solution) should be added to ERD2W?
>>>>>
>>>>> I don't remember exactly why I didn't do this, but I think it broke query validation. Hence why I wanted to make a pluggable validation delegate. The logic in there has become so overloaded, it's difficult to make changes without breaking something for someone, somewhere :-)
>>>>
>>>> I haven't yet looked into query validation. How could I test this?
>>>
>>> I don't remember what broke or how I broke it. It was quite a while ago.
>>>
>>> Pushing the propertyKey into the d2wContext there will have other consequences though. Taking a second look at the code, it looks like you'll get errors if you try this in a nested page that propogates exceptions.
>>
>> My understanding of D2W is still quite limited, so I'm not sure I really understand what this would mean. When would a nested page throw an exception for which d2wContext().propertyKey() == null in validationFailedWithException? Could we add a check via shouldPropagateExceptions() and/or shouldCollectValidationExceptions()? Or just use a copy of the context?
>
> That would be safer. Something like
>
> D2WContext c = ERD2WContext.newContext(oldContext);
>
> It's still dirty though. Remember, each nested page has it's own d2wContext. So if you are propagating exceptions to the parent page, you are probably pushing the propertyKey into a context with an entity that doesn't have that property.
>
> Example: An OwnerEO has a DogEO which has a numberOfFleas attribute. If your numberOfFleas attribute is the cause of a validation exception and it's propagated up to the OwnerEO page, you'll be pushing numberOfFleas propertyKey onto a d2wContext with an entity and object of OwnerEO. That could end badly depending on what rules are triggered after it happens.
>
> Anyway, my gut says don't do it this way :-) It has no brain, but my gut is correct with surprising frequency.
Well, I'm very much willing to accept your judgement here, but I'd still like to fix the issue. I can say "works for me" and carry on with a forked ERD2WPage. But I'd rather not, as this will make life more complicated in the future.
>> I'm creating quite a few objects in embedded page configurations here and the code does indeed get called when saving a (valid) new object that is then getting set up as the destination of the relationship. But the validation error is not getting displayed, probably because the relevant update container is not being refreshed. When clicking on next, the validation is run again and no exception is thrown.
>>
>> I've tried this with a classic ERD2WWizardCreationPageTemplate and the result is the same, i.e. the method is getting called but the exception is not getting displayed.
>>
>>>>>> It seems to me that the whole validationKeys approach is unusable otherwise?
>>>>>
>>>>> Using validateKeys would be the correct approach. But were you actually able to display the error with validateKeys on an ERMODWizard page? Last time I tried that, it didn't work...
>>>>>
>>>>> https://github.com/projectwonder/wonder/issues/97
>>>>
>>>> Well, with the modification above it works for me. That's the only thing I had to change for it to work.
>>>
>>> Good to know. If no one else is having the issue, I can close it.
>>
>> Just to be sure: I do have the issue, modifying ERD2WPage fixes it.
>
> When I had the issue, the validation exception was throwing, but it was not showing up in the page. I assumed some part of the ajaxyness was swallowing it and continuing on, because the same worked fine in a look with no ajax.
Are you sure about it working in a non-ajax look? I've just tested this using the ERMovies example app with the neutral look. The first rule below was changed so that a tab for studio is included and the second was added:
333 : (pageConfiguration = 'EditTabMovie' or pageConfiguration = 'EditWizardMovie') => displayPropertyKeys = ("[Title Information]",title,trailerName,dateReleased,"[Studio]","(Studio)",studio,"[People]","(Directors)",directors,"(Actors)",roles)
333 : ((pageConfiguration = 'EditTabMovie' or pageConfiguration = 'EditWizardMovie') and tabKey = 'Studio') => validationKeys = (validateStudio)
My validateStudio() method:
public void validateStudio() {
if (studio() == null) {
System.out.println("Movie.validateStudio: throwing! ");
throw ERXValidationFactory.defaultFactory().createException(this, "studio",
null, ERXValidationException.MandatoryToOneRelationshipException);
}
}
Exceptions from property-level components (e.g. movie title) are handled correctly, but the exception on the studio relationship falls through. The exception does get thrown.
>>>> I still wonder why this missing validation seems not to bother anybody.
>>>
>>> I think it's more complicated than that. The property key is not guaranteed to be an attribute or relationship. But if you'd like to try something different, you can always clone the wizard page template and create your own logic.
>>
>> Sure, I'm not saying it's a simple thing to do and I certainly don't want to complain.
>
> I didn't mean to imply you were complaining :-)
Just wanted to make sure...
> I have my own look framework for this reason. My wizard page doesn't even have a next/previous button on it. Everything is handled through delegates that I can switch out on a whim. Just because something isn't already done in wonder doesn't make it wrong. But at the same time, we can't just change behaviors that others may be dependent on either.
>
>> I guess I'm just so impressed with D2W and all the things people have implemented already that I feel I must be missing something here. It should be possible to check which property keys are being displayed on the current tab/step, then check for each of them whether it's a mandatory relationship and validate accordingly.
>
> Devil's Advocate: There's always willUpdate(). How do we know that a mandatory relationship isn't going to be auto-populated by the business logic if left empty? Conversely, how do we know if a propertyKey that's handled by NSKeyValueCoding.ErrorHandling is or isn't mandatory? You'll certainly need more than just the propertyKey to know.
I'll happily use validationKeys for now, it just has to work. ;-)
cheers, Fabian
>>
>>>> I'd expect validation of mandatory to-ones to "just work". It's no fun if you edit something and on the 7th step you're told you forgot to set a property on the 1st step. Or is there something I'm overlooking?
>>>
>>> It would also be no fun if a validation error from step four showed up in step one :-)
>>
>> ;-)
>>
>>> The EO can't be validated until the last step when creating. If you want to validate parts of the EO before leaving a step, then validateKeys is currently the place to do it.
>>
>> Thanks, it's good to know I'm not ignoring something helpful.
>>
>> cheers, Fabian
>
_______________________________________________
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