Disable parameters / columns by default for concepts (layouts, contexts, defaults)

Great idea René.

This also prevents that program objects result in errors because you have added a (calculated) column and forgot to deploy the functions.

In line with this, I would also like to be able to enable/disable these parameters from within the Functionality. Either from the Assigning-tab or the Result-tab. Both show the program object and thus must be easily extendable to show them.

I would like add to this idea by making this a configuration setting instead. For smaller applications or less-experienced SF users it makes more sense to have all columns/parameters at their disposal. For the larger applications and the more experienced users it makes sense to not activate these by default. 

 

Why not automate it? Based on the code-templates it could be figured out what parameters are required to be passed to the default/layout/context procedure. This way you don’t have to worry about it and you also don’t have too many values passed trough to the procedure.

Heck, if you write some smart regex you can probably do this already via dynamic model.

@Robert Jan de Nie We actually took on your suggestion and had a Thinkwise consultant on our project create such a Dynamic model procedure. Would it be of added value to have that script added to the ThinkStore?

@Robert Jan de Nie , @Arie V ,

Having this in place would, I suppose, greatly improve the ability to do an impact analysis on code; after all, you won't have to account for layouts, defaults and contexts if non of the impacted columns are used in their interfaces.

@Boudewijn what kind of impact analysis are you suggesting? Nr of code lines / performance impact / …?

@Arie V impact of removing/replacing/renaming columns. Code search gives some insight in whether a string with the same characters is used somewhere, but not whether it is the actual same object that is being referenced.

For example, if you are splitting ‘customer.address’ into seperate fields, having mentions of `address` (or ‘[enitity_address]`...) in templates in code search results does not help a lot.

If you, in that case, exclude all application logic that does not have `address` in the generated parameters, the leftovers will use the actual field instead of a coincidental identical string of characters.

@Boudewijn Understood, it saves you the ‘false positives’ in the Code search, so to speak. That's indeed another benefit of implementing this Idea!