Hi all,

While analyzing a tabbing issue I noticed that setting the "Enable" property to "False" on dropdowns and inputs results in different behaviors. Dropdowns (select) get disabled="disabled", while inputs get readonly="readonly"

Can anyone explain me why this happens? Why aren't inputs also set as disabled, instead of readonly?

Thanks

Hi Amreen, 

Thank you for your link.

However, it only states what I already verified as well: the OutSystems platform uses "readonly" for when the "Enable" property of an input is set as "False". What I would like to know is the "why". Why do they choose to use "disabled" on dropdowns but "readonly" for inputs?

If you are only planning to Display data and not getting them back to server you should use a TEXT instead of non Editable INPUT or SELECT fields.


But for some reasons most developers choose to reuse INPUT or SELECT and just make it Non editable


If your case is to get the data back to server only READ ONLY allows that. DISABLED does not allow data to be sent back to server


so generally READ ONLY is used assuming you are using the input to send some value back to server


but SELECT, OPTION and BUTTON don't have READ ONLY functionality hence they use DISABLED .


Well, my reason is that sometimes the information is going to be editable and sometimes it won't, depending on other parameters on the same screen. Therefore, it's much easier if I just set the enabled property to false whenever I don't want the user to ba able to edit it. 

However, it is not having the behavior that I expected since they use readonly on some of the screen components. I would expect it to be coherent. 

Is OutSystems recommendation that we actually "duplicate" the screen information if we want to make it non-editable? Is that recommendation documented somewhere?

Thanks


Hi Maria,

Can't really speak for OutSystems, but I agree it seems to be incoherent behaviour between Inputs and the other widgets.

That being said, I'd never trust the browser, and as such would never assume that even if I set my input fields to "disabled" the user won't use the browser's own Developer Tools to enable it again and submit data I don't want them to. Given this scenario I'd either show my disabled fields as expressions instead (so there's no way they end up being submitted) or I would always check on the server side which fields I'm expecting and only use the values from those ones (likely more work) - the disabled fields become just a UI detail, not relevant to my business logic.

Simply relying on "disabled" to prevent data from being submitted is not safe.

mariap wrote:

Well, my reason is that sometimes the information is going to be editable and sometimes it won't, depending on other parameters on the same screen. Therefore, it's much easier if I just set the enabled property to false whenever I don't want the user to ba able to edit it. 

However, it is not having the behavior that I expected since they use readonly on some of the screen components. I would expect it to be coherent. 

Is OutSystems recommendation that we actually "duplicate" the screen information if we want to make it non-editable? Is that recommendation documented somewhere?

Thanks


I don't see any recommendations from outsystems or anything related in their best practices. Although this is a practice used by a lot of developers for security reasons. Take a look at this post please


I guess contacting outsystems support on this matter would be best option.