Closed abstratt closed 9 years ago
You can play with a similar UI for an expense reporting application here:
http://develop.cloudfier.com/services/ui/test-cloudfier-examples-expenses/root/source/
You can already do all that by using custom AngularJS code.
$modal
to display a custom form in a modalnotification
service.$state
Besides, the domain you describe (business actions) is too large to be standardized in my opinion.
Since there is no common description of what business actions are, any model defined by ng-admin will feel artificial.
Bootomline: this is your job, not ng-admin's job.
@fzaninotto Any application needs to expose operations that complement the basic create-retrieve-update-delete primitives.
For instance, even the ng-admin sample applications have them:
Besides, the domain you describe (business actions) is too large to be standardized in my opinion.
It's OOP 101, right? (objects = structure + behavior). Most REST APIs end up needing something like that, as not everything can fit CRUD.
I understand that ng-admin cannot do that right now, and that is technically possible to roll your own support (however that misses the point: operations are an intrinsic part of any back-end application/API, and there would be value in supporting them out of the box).
I am disappointed that you are not even open to entertain the idea, or even considering accepting contributions. For instance, I built support for actions/operations in similar frameworks and would entertain the idea of contributing such feature to ng-admin, but if the ng-admin committers would not be interested in accepting a contribution of said feature, then I probably should direct my energy elsewhere.
Please reconsider.
You probably misunderstand the objectives of ng-admin. It is not a general purpose frontend framework. That would be Angular or react. Ng-admin is here to ease the common work of building an admin ui on AngularJs based on a REST API - not to replace Angular.js. Anything that ng-admin doesn't do, you can do with Angular.
Commands are usually not RESTful - that is to say that the standards for commands is even looser than the one for CRUD. I agree that most admin apps have commands, but defining a single syntax to define them is, in my opinion, getting in the way of the developer.
But the open-source contribution process on GitHub goes like this: you have an idea, you implement it. If you want to contribute it, you open a pull request, and the project owners see if this fits their vision. If yes, it's merged, if not, well you still have a working for with your own added feature. No big deal here.
So instead of saying no, I'm saying: show me. If it's convincing, well thought, tested, documented, and applicable to most use cases, we'll merge it.
Ng-admin is here to ease the common work of building an admin ui on AngularJs based on a REST API
@fzaninotto we are on the same page here. We just disagree on whether providing support for invoking commands on that REST API is part of that mission.
defining a single syntax to define them is, in my opinion, getting in the way of the developer
Commands must invariably be implemented via a POST. In terms of the representation, I am assuming the same kind of massaging using Restangular that is promoted for the CRUD features should be enough.
you open a pull request, and the project owners see if this fits their vision. If yes, it's merged, if not, well you still have a working for with your own added feature
Fair enough. But I would rather have a feeling of what the mindset of the project is. If the proposed change is not welcome even at a philosophical level, and for some reason it cannot be done without some change in the base code, it is probably wiser to look elsewhere (I would not be keen on maintaining a fork).
So instead of saying no, I'm saying: show me. If it's convincing, well thought, tested, documented, and applicable to most use cases, we'll merge it.
Thanks, that is good enough, and I will give it a try. I am not a JS developer (I actually dislike it with a passion), so if I manage to address this on my own, I may need some help from you to get it in a mergeable shape.
@fzaninotto I gave a try at this, but from what I could learn the current design is too centered on the concept of entities as static entities, adding support for commands/actions may require a significant overhaul of what is there right now. I may look into adding it on the side (within my own apps/framework), without using the existing dynamic UI/REST infrastructure, but that may require considerable reinvention of what you guys already provide.
You guys built a very impressive project so far, yet the lack of support for domain actions is a showstopper for me. Hopefully this can be addressed natively sometime ng-admin's future.
For completeness, the following project was born of a reluctant attempt at borrowing the basic idea of ng-admin, and expand it to support richer domain models: http://github.com/abstratt/kirra-angular
Actions are an integral part of an object domain model just are entities, attributes and relationships. While ng-admin provides good support the the last three, you need to roll your own code to support actions. This is a request for a feature that would expand the ng-admin configuration model and generic UI rendering to allow applications to describe actions, their parameters, and how to invoke them on the backend, without having to resort to workarounds (such as described in #665).
Actions in a REST API
Actions are typically exposed as POST endpoints.
Actions in a CRUD UI
Actions are typically exposed beside the entity instances, at the top/bottom of a list of instances that can be selected (if a batch action or a 'entity-wide' action), or in some top-level view if it is a global action. Actions should also be exposed in instance-focused views, such as "edit" or "show" views.
Actions often require parameters, which requires a form view just like ng-admin supports for entities (but in this case the fields map to parameters, not entity attributes).
Since actions cause a modification on the server, some sort of processing indication is recommended.
Examples
Exposing actions (Book Service) for entity (Car) instances:
Taking parameters for an action: