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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
