The ability to configure enabled state of a button based on an expression has been a seismic improvement for architecting app logic. It makes error handling so much easier and at times even has prevented me from adding steps.
This same pattern could be applied to inputs for similar benefits. Preventing users from accessing input fields could be done in an extremely similar way-- I believe just setting the html element to a status of disabled.
For a simple example, this would allow for Add Record and Edit Record pages to be very easily consolidated into one step, where certain fields are usable if the record is null, and certain fields are disabled when you are editing. This way certain fields could be locked from editing.
There are probably many other examples. This would also have the benefit of ignoring the disabled input field while tabbing through an application.
For some data presentation we show data from the loaded table record as an input widget (e.g. a boolean showing sampling or cleaning required as the table record). This avoid duplicating the data into a variable after loading. But we don’t want the operator to click it, so we place a transparent box over the widgets. Obviously this isn’t really a bulletproof solution as the users can tab their way to the widget and use space to change the value as shown in video below. Null/blank values are also not depicted so well for input boolean widget.
I fully support your idea.
I agree with @RP94. In terms of use cases, there are probably many ones, all business-specific. It is thus hard to formulate them in a generic way… I’m gonna try though:
Easily implement a step that is usable both for adding or modifying records: The ID field would be editable when adding or would be non-editable when modifying an existing record.
Disable fields that should not be filled based on the values of other fields: E.g., if a checkbox Cut material is unchecked, this would empty the number input Cut length and prevent the user from inserting a value that would not make sense anyway.
Disable a field whose content is used with a LOOPER v2 custom widget: This would allow disabling the field before starting the loop and prevent the user from modifying it, making it the same for every loop iteration.
@shep This topic has been here for at least 6 months now. Would you mind putting this topic in the Product Suggestions category? It obviously is one and would probably get many upvotes.
@danielpomeranz Thanks for this suggestion! We cannot vote for it as long as it remains in the General category though To avoid this next time, put the topic you create in the Product Suggestions category.
Beside the fact, that it would be very useful, this would also be a step in terms of consistency.
All inputs should have this function.
It is only a logic to decide if you add the disabled attribute to the html-tag.
Since tulip has this logic already built for buttons you should copy it to other inputs as well.
And while you do so, also add the same logic for the hidden attribute as well. It is 98% the same thing!
I really appreciate, tulips latest updates in those topics. But sometimes I wonder, why it is not added to all widgets where this could be useful.
To avoid this next time, put the topic you create in the Product Suggestions category.