Developer Roles / Views

This is an idea I've been working around for a while but my next JEDI idea makes it a good time for this item to be raised.

When browsing to a class we will see all the methods and properties shown (provided show protected etc is turned on.) What if you want to view that class in the view from the outside (accessor), it is a polluted view and more to sort through. But in theory if we follow OO principles I shouldn't need to know exactly how the blackbox does anything. The work around is show/hide protected methods. &Alt + &View + Show Prote&cted.

Now I have come across a situation when if you run unit tests you also see the protected and non-unit test methods. I can see the list of methods easily getting long. However my current developer role is a unit tester. Work around would be to create redundant code so there are less non-unit test methods.

The idea here is to introduce developer roles or views. Where depending on your current role it will show or hide certain methods/classes and attributes. One idea how to implement it, if turned on, is to have some radio boxes on the GUI to select the role you are in.

It can be a stepping stone towards more easily locking down views/security based on role.

Guest
May 1 2019
IDE Backlog

IDE & debugger

HistoricalComments

Brian Johnstone 27/07/2018 3:50:51 PM
For our Unit Testing we either add unit testing specific 'getter/setter/wrapper' methods on the subschema copy classes in the Unit Testing schema or we use combinations of 'get/setPropertyValue' and 'sendMsg/sendMsgWithParams' to get/set/execute protected properties/methods respectively. Either way, it means when viewing the classes outside of the Unit Testing subschema there is no 'pollution' of the view with things added solely for Unit Testing purposes and you can still leave things 'protected' for encapsulation purposes.

Kevin Saul 10/07/2018 2:17:38 PM
With regards unit tests in particular .. there's also been some internal debates in the past about keeping features protected for encapsulation vs. making them public for the sake of unit tests. It'd be useful if unit tests were allowed to access/test protected features, so we didn't have to change how we'd otherwise prefer encapsulate behaviour.

Kevin Saul 10/07/2018 2:12:52 PM
Perhaps a "Sort By Visibility" option would be simpler? Where the most accessible features would be listed first (still sorted by name), with least accessible features shown last.

In the past, we've had conventions where we prefixed a protected method with a z to keep it at the bottom of the list, but this is a work-around which falls apart when you want to change the access of an existing method.

Comments (0)
Votes (2)

Attach files

Enter a subject

JADE Environment Development Ideas

What's new in the upcoming JADE release?

IMPROVED DEVELOPER EFFICIENCY. ENHANCED SECURITY. SMOOTHER INTEGRATION