I've raised ISIS-1236 for extending RO viewer to support the "simple" domain model (to integrate with Spiro), and I've raised ISIS-1237 for Swagger integration work.
will aim to address ISIS-1236 as part of 1.11.0. Thx Dan https://issues.apache.org/jira/browse/ISIS-1236 https://issues.apache.org/jira/browse/ISIS-1237 On 14 October 2015 at 08:42, Dan Haywood <d...@haywood-associates.co.uk> wrote: > 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 <o....@govertis.com> > 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 <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 >> >>>> >> >> >> > >
