RFC: Uci components #40
Conversation
| var self = this; | ||
|
|
||
| return function(modelValue, viewValue) { | ||
| modelCtrl.uciValidator = ''; |
There was a problem hiding this comment.
The double meaning of uciValidator confused me here. Within this module it appears to be both used for a uci validator instance and for the resulting error message. Maybe we should rename the message property to uciValidationResult or uciValidationMessage ?
There was a problem hiding this comment.
I agree, will change it to "uciValidationMessage"
|
Apart from the minor nitpick above I think we should merge this and continue on top of that. |
|
Ok, I'll complete the work on a basic "saving" functionality, use it to create some simple config page and then merge this. (So as not to pollute the main repo with many fixes afterwards). |
Alternative approach to implement uci editing UI. The idea is to split functionality in three parts: 1.- Angular Components that manage UI interaction 2.- Data model that is linked to the view to hold updated data 3.- Service that syncs model data changes to UCI files This commit is an initial partial implementation. Signed-off-by: Adrian Panella <[email protected]>
Basic page to test new uci components approach. Signed-off-by: Adrian Panella <[email protected]>
Change message property in uciValidator. Signed-off-by: Adrian Panella <[email protected]>
Signed-off-by: Adrian Panella <[email protected]>
Signed-off-by: Adrian Panella <[email protected]>
Signed-off-by: Adrian Panella <[email protected]>
|
Completed basic saving and reset functionality. The workflow used when pressing the "save" button is:
It's still pending to implement all the error handling. |
|
Will continue work in Angular 4 package started in #42 |
This is an alternative approach to the current cbi implementation. To avoid name collisions and to keep current functionality, everything is in the "uci" prefix namespace, but eventually this should be changed.
In the current approach cbi is implemented as directives that heavily interact with each other in various ways including accessing each other's scope. The directives are responsible not only for UI interaction but also have responsibility in the workflow of persisting data to the uci files.
This makes it more difficult to build flexibility in pages definitions (some problems discussed in issue #36 ).
The idea in this alternative, is to implement the functionality but split in more isolated objects:
1.- Angular Components that manage UI interaction (switching from Directives to Components to enhance encapsulation and eventual migration to Angular2)
2.- Data model that is linked to the view to hold updated data
3.- Service that syncs model data changes to UCI files
In this way components only handle UI and use native Angular data binding to a model holding the data, no specific UCI interaction is handled here.
The data model is used to pivot with the view via the components and with the underlying UCI file via a service that handles all that interaction on any changed/added/deleted data.
Components could be defined in two ways:
This Components also switch from Boostrap to Angular Material library.
Additionally, a wrapper around cbi validation is added in order to use the standard Angular form validation functionality, and remove all need of specific code in each component.
Up to now this is a RFC and a proof of concept, and not all functionality is implemented yet. (for instance, only reading UCI files, no saving yet)
A very simple test page is included in the menu under Tabbed - Tests - UCI