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 mailing list