Stream: implementers
Topic: Rails
Hannes Ulrich (Mar 10 2016 at 22:39):
Hi! Since I just joined the chat and I'm working quite a bit with FHIR and with Ruby on Rails I'm interested: why is there no server implementation with Rails. I think it a very scalable environment with good tools. Are there any concerns?
Grahame Grieve (Mar 10 2016 at 22:40):
no one has proposed to do one
Grahame Grieve (Mar 10 2016 at 22:40):
generally, the concerns for any open source implementation are - can you support it, what's your scope and focus. but it's not because we don't like rails
Hannes Ulrich (Mar 10 2016 at 22:44):
I see the point of supporting and maintaining the server system. I was just wondering. So just a general question: are there people interested in developing a Rails version?
Grahame Grieve (Mar 10 2016 at 22:45):
looks like crucible is written in rails
Hannes Ulrich (Mar 10 2016 at 22:48):
Can you describe your concerns ?
Andy Stechishin (Mar 10 2016 at 23:37):
There is a server implementation done in Rails, I haven't open-sourced the generation code yet
Andy Stechishin (Mar 10 2016 at 23:40):
Most of the ORM is specific to a PostgreSQL based storage system. I am currently working on the polishing up the generators so that rather than a complete reference implementation it gives you the ability to pick and choose your resources
Grahame Grieve (Mar 10 2016 at 23:47):
Looks like Crucible is done in rails
Jason Walonoski (Mar 11 2016 at 12:57):
Crucible is written in rails, but it tests server implementations against the specification --- we do not [yet?] implement a rails FHIR server... though we have the DSTU2 mongoid models to do so, if rails/mongo stack was of interest as a starting point.
Andre Quina (Mar 11 2016 at 13:38):
@Andy Stechishin if you open source your ruby model generation let us know. We currently have ruby model generation at: crucible model generation. Since you are PostgresSQL based and we're mongo based maybe that's an impass, but maybe there's a way we could work with a common core.
Jason Walonoski (Mar 11 2016 at 13:40):
I'm also about to generate the STU3 models from the StructureDefinition files directly, and do everything outside of the Java build tools.
Brian Postlethwaite (Mar 15 2016 at 02:59):
When you get to that @Jason Walonoski the dotnet client is generated from the StructureDefinition files too, Namely: expansions.xml, profiles-resources.xml, profiles-types.xml and search-parameters.xml
Brian Postlethwaite (Mar 15 2016 at 03:00):
(and code generation is on github too - though is done with t4 templates - an MS compiler tool)
Vadim Peretokin (Mar 15 2016 at 03:00):
That file list is actually useful for me too, thanks Brian
Brian Postlethwaite (Mar 15 2016 at 03:01):
(And my server code generates off the dotnet client using reflection on the model classes)
Jason Walonoski (Mar 15 2016 at 12:44):
@Brian Postlethwaite thanks for pointing out expansions.xml and search-parameters.xml -- I missed those files. Does expansions.xml just contain all the content in valuesets.xml that has already been recursively included? Or is it something more?
Grahame Grieve (Mar 15 2016 at 17:19):
Jason, it contains all the value sets used in enumerations, expanded and ready to go so that there's no need to use terminological reasoning on the value sets
Grahame Grieve (Mar 15 2016 at 17:20):
We use it to generate the pascal and c# versions, and it's the best approach. The java RI is still generated the other way, but that's a process issue for me
Last updated: Apr 12 2022 at 19:14 UTC
