I guess the swagger schema implicitly handles access on path level. They specifically mention that the paths object may be empty due to user rights. For my purposes I'm primarily interested in loading the api schemas from the swagger endpoint who would dynamically generate them. For an authenticated user I guess they would only get the paths that they have right to. I don't think I would have to do much (if anything) to support that. For more granular access, like field level rights, we would need support from the schema if a server exception would not be enough.
resources[resource.name].api = $resource(operations[relativePath].url + '/:id', { id: '@id' });
var entities = resources[resource.name].api.query();
scope.entities = entities;
resources[resource.name].entitites = entities;then in the view:
ng-repeat='entity in resource.entities'and
ng-repeat='entity in entities'First ng-repeat doesn't work, second does...I'm missing some intricate promise checking logic I guess.
I must say that the timing of this couldn't have been better, I have planned to start building these things in just a couple of weeks. What is the problem?
I should mention that I maintain a component for dynamic drop downs from the backend for ASF: https://github.com/OptimalBPM/angular-schema-form-dynamic-select
That should probably be very easy do handkle.
I should mention that I maintain a component for dynamic drop downs from the backend for ASF: https://github.com/OptimalBPM/angular-schema-form-dynamic-select
That should probably be very easy do handkle.
That sounds like a scope-related problem, do you have the full code somewhere so I can see it?
I am trying to avoid putting it directly on the scope just.
since
resourceis already on the scope.
Or something?
Or if you are up for it we could have a quick screenshare or something?
Thing is, as you are referencing resources without scope.resource (or $scope.resource) in the controller, it would seem as it is not a scope variable and hence not visible to the view.
Oh, I see now that I misunderstood you earlier.
With regards to the nodes, it is straightforward; the MBE tree reads nodes from a web service.
The point however is that each node(basically all entities of data) has a schemaId which defines its structure and rules and is connected to a schema and a form. That combination is then used by the MBEFE together with ASF to generate a nice(it will be) tree and dynamically editable nodes.
Currently it reads the forms from a file, but the next version will read them from the database. I think.
I haven't decided on the schemas, possibly, that part will be a bit of both. At least those that belong to MBE or any system that uses it is likely to be files for versioning and deployment purposes. I mentioned the ability to upgrade the database structure based on different schema versions(most schema changes when it comes to non-process data is pretty simple anyway).
I will probably store all old schemas in the database so that any old structure can be resonably handled and remove them when there are no such documents left.
The thought is that the form later on should be generally user editable in conjunction with the ASF form designer (that is a project that will pick up steam this autumn, I hope).
The point however is that each node(basically all entities of data) has a schemaId which defines its structure and rules and is connected to a schema and a form. That combination is then used by the MBEFE together with ASF to generate a nice(it will be) tree and dynamically editable nodes.
Currently it reads the forms from a file, but the next version will read them from the database. I think.
I haven't decided on the schemas, possibly, that part will be a bit of both. At least those that belong to MBE or any system that uses it is likely to be files for versioning and deployment purposes. I mentioned the ability to upgrade the database structure based on different schema versions(most schema changes when it comes to non-process data is pretty simple anyway).
I will probably store all old schemas in the database so that any old structure can be resonably handled and remove them when there are no such documents left.
The thought is that the form later on should be generally user editable in conjunction with the ASF form designer (that is a project that will pick up steam this autumn, I hope).
Ok, for swagular the approach is different, it is really a generator for a standardized CRUD UI which will work with Swagger documented endpoints. So there are a few challenges which will come up sooner or later like master/detail views and customized forms generation (e g angular-schema-forms form schema).
This approach may not be relevant for MBEFE but I'd like to see swagular grow into being able to generate a UI with tree representation of entities as on option to a grid, but that presupposes some higher level of description of the relationship between endpoints which I'm not sure Swagger has defined.
Actually MBEFE is exactly a generator for a standardized CRUD UI. It just doesn't work with swagger right now.
MBEFE is just an early version of a tree component, it doesn't have to end up working the way it does now.
What I am thinking is that swagger is a part of the solution. If it is like JSON-schema, it can be extended.
But I am not sure how far one should take the "declarativeness" of the solution, it is easy to be locked up in the limitations.
For example, I am not completely certain of the actual gain with creating master-detail views through declaration.
One should remember that Angular itself has lots of valuable features for those cases.
For example, I am not completely certain of the actual gain with creating master-detail views through declaration.
One should remember that Angular itself has lots of valuable features for those cases.
On my part I'm focused on fully automated generation that happens on demand. I realize the weaknesses this has in terms of UX but I can live with that. Ideally that should be solved by being able to grab an autogenerated front-end schema and continue to customize it and later deploy without swagular/swagger dependencies.
Hm. I would say there are going to be significant UX problems. Unless what you are making would be little more than a "swagger-service-explorer", customer demands would be very hard to meet.
Solutions like that tend to become very complicated and basically replace easy-to-read code with unreadable declarative syntaxes and difficult concepts(I am mostly thinking of some of the more advanced report generators, and they don't even support input).
But of course, If one could do that nicely, it could be very usable.
Solutions like that tend to become very complicated and basically replace easy-to-read code with unreadable declarative syntaxes and difficult concepts(I am mostly thinking of some of the more advanced report generators, and they don't even support input).
But of course, If one could do that nicely, it could be very usable.
I'm not aiming for an end user UI but rather a replacement for all the tedious boiler plate code we have to do for the "plumbing entities" that each app has but is almost never interacted with by end users. This would enable us to focus more time on the UI parts that users will use 80% of the time.
Aha, I see. Personally, I always just put those little buggers in a generalized tree. That is why I started with a tree.
I realized that customers actually like working with entities in trees.
Anyway, to one could do, then, is to create a forth declarative syntax that works on the application-level.
So one ends up with:
- Swagger
- The JSON-schemas that swagger will reference
- Forms for input niceties (like ASF)
- An application-level "form", that binds all elements together.
With regards to number four, I am not sure that it is needed, because Isn't that basically the swagger framework and Angular in unison?
Shouldn't swagger be an angular framework that doesn't have a form standard, but which, with minimal input, can generate a UI but have several ways to be controlled?
I am thinking more in the lines of a swagular directive.
Let's say that directive can have sub-elements, like "master", and "detail". And so on.
The swagger spec is YAML/JSON for describing endpoints including the models/schemas/parameters for each operation on an endpoint. So 1-2 in your list is actually just 1. I haven't looked in to if the Swagger spec already defines a place for a json-form schema but I think it fits within the spec and then the back-end could pick a way to include it if it wants to (this is something I didn't look into much). Master/Detail and other replationship between different entities is supported by the Swagger spec when I come to think about it, that's why I have to resolve those pesky circular references...
And yes, I have a directive for this (so far just one big fat ugly one).
It should be split up to allow more customization and I still need to separate the concerns.
I thought that splitting was what I did, do you mean along other lines?