Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Pontus
    @pontusr
    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.
    Nicklas Börjesson
    @nicklasb
    Yes, 3 would be the form schema. With regards to group level permissions and/or rights, I am not sure what is possible through swagger and in what way those things are configured.
    I would have to look in to that.
    Pontus
    @pontusr
    Just documented my hacks so far to share them with you. But I need to solve one angular newbie issue first.
    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.
    Nicklas Börjesson
    @nicklasb
    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.
    That sounds like a scope-related problem, do you have the full code somewhere so I can see it?
    Pontus
    @pontusr
    I just went busy with more life than I had planned for today and it seems I'm running out of time to do it properly. It's not ready as full code.
    I am trying to avoid putting it directly on the scope just.
    since resourceis already on the scope.
    Nicklas Börjesson
    @nicklasb
    Could it be that resources[resource.name] isn't the same thing as resource ?
    Or something?
    Pontus
    @pontusr
    No, it's the promise that doesn't resolve when iterate over it as a property of a resource. If I put the promise directly on the scope ngrepeat works fine.
    Nicklas Börjesson
    @nicklasb
    IS resource really in the scope and not just a local variable? There is no scope.resource = something?
    Pontus
    @pontusr
    Yes, it is, it carries a lot of other stuff which is accessible fine. Just the promise is the issue. Gotta read up a bit. Maybe I have to add some $watch...
    Or if you are up for it we could have a quick screenshare or something?
    Nicklas Börjesson
    @nicklasb
    Sure, I am up for it.
    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.
    Pontus
    @pontusr
    Nah, I just didn't share all of the code. pontusr on skype if you have time.
    Nicklas Börjesson
    @nicklasb
    Sent you a message.
    Oh, I see now that I misunderstood you earlier.
    Pontus
    @pontusr
    Hi @nicklasb, about to spend a little time on swagular again as I solved my scope issue.
    Before I dig into to your MBE angular tree, does it parse the JSON schema of the service to drive the generation of the nodes and/or do you know if something out of ASF could be used to do that?
    Nicklas Börjesson
    @nicklasb
    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).
    Nicklas Börjesson
    @nicklasb
    I just saw that the demo site had stopped working, started that again just a while ago. (interesting that it has actually been up as long as it has)
    Pontus
    @pontusr
    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.
    Pontus
    @pontusr
    For the customized forms generation I think it should be possible to add some custom stuff to the Swagger documentation which could be handled for more granular control of the UI generation but that has do be dealt with later.
    Nicklas Börjesson
    @nicklasb

    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.
    Pontus
    @pontusr
    It looks like it should be a good match once I can commit something that generates a UI.
    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.
    Nicklas Börjesson
    @nicklasb
    Like, "here is a swagger service. here you have a UI for it"?
    Pontus
    @pontusr
    exactly
    Nicklas Börjesson
    @nicklasb
    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.
    Pontus
    @pontusr
    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.
    Nicklas Börjesson
    @nicklasb

    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:

    1. Swagger
    2. The JSON-schemas that swagger will reference
    3. Forms for input niceties (like ASF)
    4. 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.
    Pontus
    @pontusr
    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).
    Nicklas Börjesson
    @nicklasb
    I mean, a swagular-app would then look like:
    <swagular>
        <master></master>
        <detail></detail>
    </swagular>
    Pontus
    @pontusr
    You just call it like so: <swagular url='https://localhost:444/docs/1.0' />
    It should be split up to allow more customization and I still need to separate the concerns.
    Nicklas Börjesson
    @nicklasb

    Yes, 1 & 2 looks the same, but in actuality, they are pretty different and will be handled differently in any non-trivial system.
    However, I realized that perhaps doesn't matter in this case.

    Yes, but I didn't add the url parameter.

    I thought that splitting was what I did, do you mean along other lines?
    Pontus
    @pontusr
    I mean splitting up my one directive to rule them all into some nested directives to allow for more granular control if one needs it.
    Nicklas Börjesson
    @nicklasb
    I thought that was what I did above? That is why I don't understand?
    Pontus
    @pontusr
    Ahh, sorry, too tired for this. Yes, something along those lines.
    Nicklas Börjesson
    @nicklasb
    Haha, I had no idea there for a while. :-)
    Pontus
    @pontusr
    :)
    Nicklas Börjesson
    @nicklasb
    Anyway, then it is just a question of organization of directives.
    What are the points of control needed?
    1. We spoke of master detail, that is why I listed them, most UI:s are some kind of M/D, MBEFE-too(just self-referencing).
    2. ...
    3. profit!