isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: Spiro support in Isis
Date Tue, 03 Nov 2015 00:36:25 GMT
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 <dan@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.bou@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 <dan@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.bou@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 <dan@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 <darabi@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 <dan@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" <darabi@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
>> >>>>
>> >>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message