OK, let me put a day aside to get a better handle on all this cool stuff. Thanks for the links.
Cheers Dan On 14 October 2015 at 08:29, Óscar Bou - GOVERTIS <[email protected]> wrote: > > > 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > >> 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 <[email protected]> > >> 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 <[email protected]> > >>>> 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" <[email protected]> > 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 > >>>> > >> >
