Hi Dan.
You know we're using Wavemaker for the front-end. Most recent version 7 uses Swagger as the way to document the auto-generated APIs [1], but all JavaScript widgets can be render any JSON representation with limitations detailed in [2], [3]. [1] http://www.wavemaker.com/latest/wavemaker-api-designer-brings-api-driven-development-to-custom-built-enterprise-applications/ [2] http://www.wavemaker.com/learn/topics/studio/integrate/external-services/ [3] http://www.wavemaker.com/learn/docs/importing-web-services/ Disculpa que sea breve. Enviado desde mi móvil > El 14 oct 2015, a las 9:07, Dan Haywood <d...@haywood-associates.co.uk> > escribió: > > Hi Oscar, > > I think that Swagger is a mechanism primarily for documenting > representations, rather than specifying them. > > But I haven't played with it, so I might be wrong. > > I do also think we should provide a Swagger (or Blueprints, or RAML) > integration, though. > > I guess maybe I need to roll my sleeves up and dig into all this (sigh). > > Thx > Dan > > > > On 14 October 2015 at 08:04, Óscar Bou - GOVERTIS <o....@govertis.com> > wrote: > >> >> Sorry for this, but would be of any help to fully support something like >> Swagger (perhaps there are better options; thought it was somewhat >> supported through Maven?) ? >> >> If all we could agree on a common well-known standard in addition to RO >> specification it would help our current custom viewer projects and others >> to come. >> >> Thanks, >> >> Oscar >> >>> El 14 oct 2015, a las 8:53, Dan Haywood <d...@haywood-associates.co.uk> >> escribió: >>> >>> Hi Kambiz, >>> >>> my apologies ... responding to your mail fell off my todo list. >>> >>> It seems that Willie (just posted on the mailing list) has similar >>> requirements to customize the RO viewer. >>> >>> to you both: >>> >>> I'd like to accommodate these new requirements somehow... over and above >> me >>> just saying to implement your own RepresentationService. Not sure how, >>> though, other than to ask for some precise examples as to what exactly >>> folks would like to see as extensions to the "out-of-the-box" >>> representations generated by the RO viewer. >>> >>> Or, github pull requests are the best way for you to describe what's >>> needed. I can then review and if necessary add configuration flags or >>> extensions to the Accept header handling to allow the RO viewer to >> support >>> these. >>> >>> Any thoughts? >>> >>> Dan >>> >>> >>> >>>> On 28 September 2015 at 17:34, Kambiz Darabi <dar...@m-creations.com> >> wrote: >>>> >>>> Hi Dan, >>>> >>>> I wanted to ask whether you had the time to look into this. >>>> >>>> If not, I would be willing to invest some time, but would need a bit of >>>> advice on how to tackle it. >>>> >>>> Thanks >>>> >>>> >>>> Kambiz >>>> >>>> On 2015-08-17 17:32 CEST, Dan Haywood <d...@haywood-associates.co.uk> >>>> wrote: >>>> >>>>> Hi Kambiz, >>>>> No, there isn't support at the moment. >>>>> >>>>> I would imagine it would probably take a couple of days to implement >> for >>>>> me, perhaps less. For someone less familiar with the code, perhaps >> double >>>>> that. >>>>> >>>>> Once I have 1.9.0 released (in the next week hopefully) I'll spend a >>>> couple >>>>> of evenings looking at it to see if I can "break the back of it" (eg >> that >>>>> you might finish it off if you really need the feature). >>>>> >>>>> Hope that sounds OK to you.. >>>>> >>>>> Cheers, Dan >>>>>> On 17 Aug 2015 14:09, "Kambiz Darabi" <dar...@m-creations.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> is Isis capable of supporting the simple domain model as described in >>>>>> section 1.25.1 of the RO spec? >>>>>> >>>>>> I ask because of Richard Pawson's answer to my question on github: >>>>>> >>>>>> https://github.com/SpiroLibraries/Spiro.Modern/issues/2 >>>>>> >>>>>>> I'm afraid this is not going to be straightforward. Either Isis needs >>>>>>> to support the 'simple' domain model (my strong preference!), or >> Spiro >>>>>>> needs to be extended to work with the formal model (a lot of change - >>>>>>> and, inherently, much more complex than working with the simple >>>>>>> approach). I have suggested to Dan that in the next version of the RO >>>>>>> spec that the Simple domain model should be mandatory and the formal >>>>>>> one an optional extra. >>>>>> >>>>>> If there is no built-in support, I would be interested in an estimate >> of >>>>>> how much effort would be needed to implement that functionality. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> Kambiz >>>> >>
