This solution certainly needs more work from an implementer, but I think it might be worth it in a long run. Currently each time after introducing new releases of the core components to the Malawi implementation, I need to go through all files and check whether something changed in the forked files. I have to check which methods where chaged by the Malawi team, and which were changed by the core team (the core team has commits history, so it’s easy, but in Malawi first occurence of the file in the commits history is when it’s copied and already changed file from the core - so I don’t know immediatly what’s different from the core version of the file). In such decorator, it is clear what is changed and why. There is less code and it seems to me that it’s more clear, but it’s possible that there are places in the code, where it’s better to just fork and change the file.
The naming convention makes sense to me, but I don’t have a strong preference for this or any other option.
Regarding unit tests, will original tests from the directive also run during build? If yes, I understand that they will run on the original directive, without decorator? I’m not sure whether we should just run one control test to make sure that the original contract stays in place, or run all tests from the original directive (besides the ones testing “isReadOnly” method). Is there a possibility to somehow override unit tests?
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40
/ Fax: +48 58 782 45 41
Al. Zwycięstwa 96/98
Place of registration: Regional Court for the City of Gdansk
KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,
Share capital: 60,000.00 PLN
On Tuesday, 25 July 2017 04:36:55 UTC+2, Nick Reid wrote:
Here is an example of extending a directive using AngularJS’s decorator syntax. I have created a sample pull request to the OpenLMIS-Malawi/mw-ui repository to show an example of what a MW-267 could look like if refactored.
NOTE: this won’t be merged, I thought it would be the simplest way to show the changes…
Tomorrow at the Tech Committee, we will discuss this example – as it is still a work in progress
(it doesn’t really work according to my unit tests)
The goal of this work, is to create ‘lighter’ extension mechanisms, as implementers are generally making changes to the UI behavior – which has been a large cause of forking in previous versions of OpenLMIS.
I would like feed back on:
(1) Is this too much boiler plate to be worth the effort for an implementer?
(2) Does the file naming convention make sense? (ie naming the folder ‘*-override’)
The second unit test is to make sure the original contract stays in place --> is this reasonable?
(3) If extending services is simpler than extending directives, would it make more sense to only extend the services?
– nick –
Nick Reid | nick...@villagereach.org
Software Developer, Information Systems Group
VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA