[horde] Displaying of variable fields in preferences

[Jan Schneider]

Zitat von Jens Wahnes <wahnes at uni-koeln.de>:

> On Thu, Jan 21 2016, at 14:45:49 +0100, Jan Schneider wrote:
>
>> Zitat von Jens Wahnes <wahnes at uni-koeln.de>:
>>> In any event, here's what I noticed: When using the "Undo changes"
>>> button, changes to the GUI elements that had been carried out
>>> previously (presumably through some Javascript code) are not reverted.
>>>
>>> How to reproduce:
>>>
>>> (1) Go to Gearwheel -> Preferences -> Calendar, Notifications
>>>
>>> (2) In the box labelled "Choose how you want to receive reminders for
>>> events with alarms", change from "Inline" to "Email" and notice how the
>>> radio buttons for selecting the alarm sound disappear. Instead there is
>>> now a line to enter an email address.
>>>
>>> (3) Now click on "Undo Changes". The selection goes back to "Inline",
>>> but the sound selection does not reappear. The email address field is
>>> still displayed.
>
>> It's really just a standard form reset button. This resets the form
>> elements to their values specified in the HTML source. It does *not*
>> revert any changes done by JavaScript. I.e. it's a browser feature, not a
>> Horde feature.
>
> I don't think there is any browser out there that does actually track
> changes to form elements on the DOM level to revert them if the "reset
> form" button is pressed.  Other web applications that use dynamic
> changes to forms seem to use workarounds to restore a form to its
> original state (instead of relying on the browser's "reset form" to do
> the work).  That is, if they provide a way to reset the form at all.
> But I don't know if there are any rules/RFCs/best practice documents or
> such that define the expected browser behavior a situation where the
> form elements have changed and the "reset" button is pressed.

Yes, in case this wasn't clear: I don't expect the browser to reset  
those dynamically changed forms. I just explained that we rely on the  
browser's reset feature, and it does what it is supposed to do.

> However, what I do know is that from the user's perspective, the
> current behavior really creates an inconsistent feel.  What's supposed
> to happen if you submit the form mentioned before with settings
> "Inline" and an email address entered, anyway?
>
> To "really" reset the form, it would probably require additional
> Javascript code from Horde to reset all form elements to the original
> state whenever the "reset form" button is pressed.  Another way to do
> it would be to have the "Undo Changes" button just link to the current
> page's URL (e.g., to
> "/services/prefs.php?app=kronolith&group=notification" on the form I
> mentioned) because reloading the page would essentially reset the form
> to its original state as well.  While I'd expect the first approach to
> require quite some amount of additional work with little real benefit,
> the second one shouldn't be that hard to implement, AFAICS.
>
> Yet another way to deal with this would be to leave out the "reset
> form" buttons completely.  I haven't seen those at all for a while now
> in other web applications that use forms with heavy Javascript
> interaction (e.g. in Google Apps), so I guess people don't miss
> traditional HTML "reset form" buttons a lot.  Applying that design idea
> to Horde's preferences pages, one could leave out the "Undo Changes"
> button completely and label the button that currently says "Show All
> Preferences Groups" with "Cancel" instead.  What's your opinion on that
> approach?

+1 to your latter suggestion.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/