[Cmb-users] [Smtk-developers] Dealing with passwords in attributes

[David Thompson]

> I am split on my thoughts on password being a separate class. I think
> that as the use case for passwords expand to include two-factor
> passwords, resetting forms, password creation and setup of
> requirements the idea of it being a class becomes stronger.

Those all seem like auxiliary classes related to the UI, I/O, or application, not something that would be part of the attribute class that stores the value.

	David

> 
> On Mon, Feb 1, 2016 at 11:46 AM, David Thompson
> <david.thompson at kitware.com> wrote:
>> Hi John (and Yumin),
>> 
>> I think the boolean is too restrictive; we will almost certainly come up with other roles that require special processing. (I am thinking of roles related to how input is accepted but that are not UI-specific. For example, indicating that a DoubleItem should be a point on a surface instead of in the interior; that informs the UI that a point selector will work but does not specify UI elements to achieve it.)
>> 
>> So in that sense, I agree with Yumin that a single boolean is too narrow. However, I do not think there needs to be a separate class just for passwords (or any other role).
>> 
>>        David
>> 
>>> On Feb 1, 2016, at 10:12 AM, John Tourtellott <john.tourtellott at kitware.com> wrote:
>>> 
>>> I would vote for modifying StringItemDefinition to add either a boolean flag (IsPassword) or maybe a "type" enumeration with 2 choices (Text, Password). To me, the closest analog is the html <input> element, which has a "type" attribute that can be set to many different values -- e.g., button, checkbox, color, date, file, hidden, radio, url -- as well as"password" and the default "text". As for the many other "type" choices, the ones relevant to simulation preprocessing are already handled differently in SMTK; so I would go for the boolean flag.
>>> 
>>> 
>>> On Mon, Feb 1, 2016 at 8:36 AM, David Thompson <david.thompson at kitware.com> wrote:
>>>> We have a use case where we need prompt the user for a password in order to launch jobs.  ...
>>>> In order to provide support I can either add a "role" parameter to the string item indicating it is a password or create a special item/item def.
>>>> ...
>>>> Any comments?
>>> 
>>> If adding a "role" adjective to items, I would add it to the base Item time instead of just to String. It will be handy elsewhere just like in HTML5 (where roles are used by browsers to modify touchscreen keyboards depending on whether numbers, e-mail, or URLs are being entered[1]).
>>> 
>>>        David
>>> 
>>> [1]: http://html5tutorial.info/html5-contact.php
>>> _______________________________________________
>>> Cmb-users mailing list
>>> Cmb-users at computationalmodelbuilder.org
>>> http://public.kitware.com/mailman/listinfo/cmb-users
>>> 
>> 
>> _______________________________________________
>> Smtk-developers mailing list
>> Smtk-developers at smtk.org
>> http://public.kitware.com/mailman/listinfo/smtk-developers