At this moment, if I state in the SF that a detail is not visible, the parameter to make it visible is not offered to the context procedure, and the settings in the SF database always win.
This has 2 disadvantages;
1) If we change the visibility in the SF and forget to recompile the context procedure, we get an error.
2) If the internet is slow, or something goes wrong the user can see tabs, the user should not see. ( We have one place where we switch between 10 tabs … ).
It would be nice to have 3 or 4 states; show, don’t show, or only show when the context stored procedure wants it, with “this” as default ... 4 states would be possible with one additional checkbox.
This is kind of related to my previous idea, but technically requires more. User preferences can differ, and I like to build by enabling things, instead of disabling things. ( We have a row based security on top of the Thinkwise security… that is an important reason why I would like to have the possibility to only show things when the stored procedure allows it ).
Allow the context procedure to overrule the SF settings.
Software Factory
Windows GUI
Universal GUI
Indicium Service Tier
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Hi Daan,
That is correct and we decided to keep this behavior intact. If the model says something is not visible, or hidden, or not available, it is indeed unavailable.
And if you use a Context procedure to show the details when they are relevant, it will be the same to hide these same details if the are not relevant. So changing the behavior would not change anything other than adding confusion.
What you can influence, is by changing the "Context type output” setting in the SF > User interface > Subjects > Links > Details screen. Unchecking the detail there will prevent the reference from being included in the Context logic. It also happens to be the place to influence the visibility of the detail.
Visible details can be hidden using User preferences in both Windows GUI and Universal GUI.
I disagree with this; “And if you use a Context procedure to show the details when they are relevant, it will be the same to hide these same details if the are not relevant. ”
A car has a gas pedal and a break, I don’t think that you would like to drive in a car with only a break, and only a gas pedal on the highway would also be a bad idea.
The way it is now, the platform only has a break.
When I started we had code like this in our application;
If option=1: hide b,c,d,e,f -- 1 means a
if option=2: hide a,c,d,e,f -- 2 means b
That was completely unreadable, cleaned up for readability this became much shorter and more readable ( I shortened it here, in reality with the tabs / fields on different lines, the new version was 20 lines instead of 100, here the new version is a little bit longer then the old);
hide a,b,c,d,e,f
declare option_a INT = 1
declare option_b INT = 2
if option = option_a: show a
if option = option_b: show b
But this solution still has one problem; when the loading of the interface goes slow, the user gets to see a,b,c,d,e,f. While only a,b are relevant in the context.
It depends on the context and the application, and I think that the developer should have the freedom to decide which of those 2 options fit best in a situation.
This is possibly a difference in thinking is between my thinking, and the Thinkwise “way”.
As a developer I don’t want to “stop and hide”, but to “allow and give through”. My users can have the break, I have the gas pedal, and you build the engine.
Hey Daan,
Thank you for the insights in your use case. I can imagine the Context logic being more extensive than you might want it to be.
The title of the idea is the thing I disagree with, but I can get into having a new setting that indicates the default state of the reference - such as Hidden, Disabled or Enabled. This could be extended to columns, tasks, and other objects.
Shall I change the title to "Ability to pre-set the default ‘_type’ state of references and other objects” or something along those lines?
I think that having both a hidden or visible state, and a default state could become confusing.
If I say hidden, in for example the database layer, I mean hidden, but when it is a key, the key is still included in the export, while for me “hidden” means that ever showing it to a user is a bug. So, it is already confusing. In this case, as example, the platform should not show the key, and remark in the validation that import was disabled for the lack of a key.
For me this concept means that somethings stays hidden, until a positive confirmation of the control procedure. It means that the interface will never show it, until the procedure says, yes do.
I don’t know how to implement it in the current logic of your platform. But creating the possibility to program by enabling, instead of disabling, could be a huge improvement in different scenarios.
I get that, if you have 10 details where only 1 is shown based on a condition, this idea would flourish. However, there are also numerous situations where all details should be shown. If we would simply switch the default state to Hidden for everyone; I'm sure we'll get some complaints.
My idea was to change the "Show detail” to be more of an “Available” checkbox as seen for Table tasks for example. This way unchecking this box would definitively hide the detail as it is not available. Then having a separate field next to it that indicates the default state of the detail (up for debate were that place would be). Default state is of course Enabled, ensuring existing applications run perfectlyfine as before, and allowing you to set it to Hidden so you can decide when to activate it in Context logic.
So there will only be one default state per detail, but I can imagine this will become a Model setting; affecting all details in your application. Mixing use of such default state would become increasingly difficult to understand and manage.
Side-idea would be a sort of Business rule engine in which you can declare without any code what detail would be shown in what situation; but that quite a large idea.