[Framework-Team] The final(?) verdict
raphael.ritz at incf.org
Wed Feb 20 14:48:30 UTC 2008
Tom Lazar wrote:
> maybe i didn't understand you correctly, but i was under the
> impression that you had additionally suggestded that the inline
> validation should als explicitly *clear* and statusmessages. this
> would certainly address the issue you're mentioning below... at least
> i think so. *scratches head*
Yes, it does. That's why I had introduced it in the
first place. But this also has the unwanted side effect
that things start jumping up and down whenever the
portal status message gets inserted or removed.
This is annoying and therefore it is suggested to leave
the portal status message alone. But this would be
exactly what Martin submitted in the first place where
I stumbled across the issue I'm trying to raise (but seem
to be unable to describe - I wish it were a five minute thing
to do a screen cast ...)
shows the changes I introduced:
Line 66/67 issue a status message in case of an
error occurring while 71/72 clear the message
on error removal.
Prior to that change the portal status message was
Now, a variant that we might want to consider is
only to clear (but not to issue the error in) the
status message. That would address the specific
concern I have about inconsistent feedback and
make things jump around a bit less.
Still not sure what's the right thing to do here though
> just my $0.02,
> On 20.02.2008, at 13:28, Raphael Ritz wrote:
>> Martin Aspeli wrote:
>>>>> PLIP #202: Support inline validation and editing for formlib forms
>>>>> +4 - but there is still some debate about what's the
>>>>> best way to handle the portal status message. Once this
>>>>> is sorted out (and implemented) it's ready for merge
>>>> I agree with Danny that that must be fixed before merge.
>>> Do we have consensus here? IMHO, the portal message should just not be
>>> shown. It's not shown for AT edit forms as far as I recall. I'm happy
>>> to do whatever, though.
>> As I feel kind of guilty here I try once more to explain my
>> point of view.
>> In Martin's original implementation the portal status message
>> was left alone - which is what Danny is proposing also if I
>> understand him correctly - but that reveals the following issue:
>> Take the sample form shipped with the review buildout and just
>> submit the form without entering anything (by pressing 'save' that is).
>> You will get a portal status message "Error: ..." *and* the fields
>> will be highlighted as usual. Now go and enter valid input.
>> The fields will "turn normal" as you switch focus but the error
>> message in the portal status message stays around resulting in
>> a view of the form where there is an error message at the top of
>> the page but no errors present. This is what I found confusing and
>> why I introduced updating the portal status message from the
>> inline validation as well.
>> I agree that this has a negative impact on user experience as things
>> start to jump around because of the portal status message changing
>> but still I consider providing contradicting feedback to the user as
>> we had it initially to be even worse.
>> I don't know the solution to this myself and I would be happy to see
>> this addressed the right way if somebody knows what the right
>> way would be ;-)
>> Framework-Team mailing list
>> Framework-Team at lists.plone.org
More information about the Framework-Team