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