2 months ago, we open sourced ng-admin, an angular module to add a GUI to any RESTful API. This module is already widely used, especially on some of our projects.
Using our product, we noticed that sometimes we don’t need the same fields in the list and in the edition form, or in the edition form and the creation form. For instance, a creation date field, created automatically on the backend side, should not be displayed in the creation form, but it makes sense in the list and in the edition form (although is should be non-editable).
ng-admin was built with the idea that each entity is mapped to one or more fields. Originally, these fields could be configured to be shown or not in certain views using
.list(false) for instance. This syntax proved to be too limited for cases when we need different behaviors for each type of views.
That is why today, we are introducing the concept of view.
An entity can have up to 5 views (
DeleteView). Each view can have its on set of fields, independently of the other. That way, it’s easier to expose some fields in the EditView but not in the ListView, or to use different field types for the CreateView and the EditView.
This allows to display only necessary fields on each view:
var tag = new Entity('tags'); tag .addView( // in the dashboard, display only the name new DashboardView('tags-dashboard') .addField(new Field('name')) ) .addView( // in the list, display the id and the name new ListView('tags-list') .addField(new Field('ID')) .addField(new Field('name')) ) // ... ;
This was a big refactoring (with 130 files and more than 5000 lines changed), and we took advantage of this refactoring to add more tests, improve the configuration API usability, and improve performance. To mark this important step, we’re releasing a new major version, ng-admin 0.3.
As it’s a major overhaul of the configuration language, applications already using the ng-admin 0.2 configuration will stop working. We’re sorry for the early adopters who now have extra work to get their admin working with ng-admin 0.3. Check out the migration doc to see what’s changed in detail. We know that it can be a pain to use moving APIs, so we tried to pack most breaking changes in this new version. We don’t plan on breaking BC again for 1.0.
We hope you’ll enjoy this new feature and we’ll appreciate your feedback on the repository.