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 > >> >
