GSoC 2018-HTML Form Entry Module and REST

Community GSoC
42

@owais.hussain, Extending the HFE module seems like a very good idea. This will help the existing HFE to continue functioning(maintaining backward compatibility) and using REST would be optional.

But since the aim of this project is to move to REST and we are also creating an OWA for the same, i think we can also go by the first option which @suthagar23_ mentioned here GSoC 2018-HTML Form Entry Module and REST - #5 by suthagar23. and as far as backward compatibility concerning with being able to submit data filled via the forms, we can convert these forms to REST requests in the frontend just after being submitted.

3 Likes
43

@piyush9620 you’re right. And it’s probably easier to change the existing module. I’m only concerned about supporting the larger audience. HFE is the default choice for web forms and we can’t guarantee that every implementation below 2.0 will even have REST-WS module installed. Changing the existing HFE will force them to either stick with the last compatible version, or have the REST-WS module installed as a dependency. Going with 2nd choice will add a little hassle on development end, yes, but make use of RESTful service completely optional.

I might be missing the flip side though. Let’s take opinion from some of the HFE and REST authors, @mseaton @wyclif @mogoodrich @darius

44

@owais.hussain @piyush9620 @ivange94 Is building an OWA in the current project scope, in addition to extending the HFE module to REST API ?

45

@michael25 yes, building an OWA as proof of concept is the 2nd stage of the project.

3 Likes
46

The OWA could help us test the REST endpoints but other than that i doubt someone will use this OWA interface to create a REST request and then submit data. Users would rather prefer submitting via a form. nonetheless it is a part of the project it seems.

2 Likes
47

@piyush9620 @owais.hussain So submitting HTML forms with user input could be handled in older way, the only difference being form data is embedded in JSON when sending to the REST API ?

48

we are extending the current HFE module to be able to handle the data submission via REST as an option. So the user will then have an option to either submit the form as usual or call the REST endpoint(data emebedded in a JSON possibly) to submit the data.

3 Likes
49

@piyush9620 So the user has two options. When user selects to submit the form in JSON how does he manage to assign value for each field in the form where in form submission it is trival to add input in the text boxes ? I think should be able to predefine a proper format for form entry and form submission viaJSON.

50

That is what we need to figure out in this project.

Yes it will indeed be tedious to create the whole json, but to make things simpler, we could have a form specific json template that shows up when we are trying to create or edit that JSON in the OWA UI. This template could have all the keys already laid out, and the user may have to only fill the values in the json.

But again the form is a better way to go for submission via UI.

3 Likes
51

@piyush9620 Thank you very much for your support.

52

Guys plz, one thing i would like to specify is all the community members are eager to help and we see it as our duty. There is no need thank again and again especially tagging the person. It only creates unnecessary notifications. Hope you understand. I wrote this bcoz i saw a lot of thanks comments in the above thread, reducing the quality of the discussion. plz don’t take anything personally.

2 Likes
53

@piyush9620 @owais.hussain So the REST API can mainly be used for viewing HTML Forms and encounters. Should REST API be able to send the HTML to be displayed embedded in a JSON ?

54
55

@piyush9620 Thanks, then what about when the user wants to view the list of form entries ? In this case, does the REST endpoint respond with list of forms embedded in a JSON or the whole html as in SPRING MVC ?

56

@madushan have a look at this. https://wiki.openmrs.org/display/docs/HTML+Form+Entry+Module. Read the Instructions on this page. It is all a part of this module.

And the UI part dealing with filling existing forms, viewing data in them, etc is taken care in openmrs-module-htmlformentryui. There u can see all the data in forms filled for a patient, even fill new forms for a patient, etc. which eventually uses the endpoints provided by the htmlformentrymodule(but the thing is these endpoints are not RESTified).

I believe, there are 2 different things, one is the html forms, their maintainence, building new forms etc and the other thing is being able to submit data via these forms, view data filled in these forms, etc. and in this thread we are talking about the latter. (but both functionalities exist in the same module is what i understand form all the above comments)

But your point could be valid, what we could do is also create REST endpoints for creation, deletion, management etc of new forms, if these endpoints don’t already exist. @owais.hussain can u plz help clarify this point.

57

@piyush9620 Thanks for clarification, so what we should worry about is submitting of these forms, not a lot about what the response of the API ?

59

@owais.hussain Yes please be kind to clarify on what should be the response of the API , when a user wants to view the list of Form Entries? is it a list of Form Entries embedded in JSON or a whole HTML page in a JSON ?

60

Hmm… I’m a little confused as to what the downside would be to creating an “htmlformentryrest” module as opposed to adding REST support directly to htmlformentry, beyond a little bit of overhead as @owais.hussain suggests. Is there something I’m missing?

I think trying to change all existing HTML Forms so that they work RESTful, while great if it could be accomplished, is too big a chunk of work to take on. I think we create a new “RESTful” way of submitting forms in an “htmlformentryrest” and then work on a path to migrating existing forms for those who want to.

Regardless, I think there will be a lot of design work required up front that I should probably see if I can carve some time out and work on. :slight_smile:

Take care, Mark

3 Likes
61

@madushan here’s what I think:

getAllHtmlForms() should return: https://pastebin.com/T4uwZt3V

getHtmlFormPage(String uuid): https://pastebin.com/ZxawZ2t7

Does it make sense?

2 Likes
62

@owais.hussain Thank you very much for the links. getAllHtmlForms() return the current htmlForms with their basic details, while the other returns a response for single HTML form. But here the client would not be able to render the HTML form as it is in xml format :slight_smile:

1 Like