What I wanted to say is - think of separating dataentry screens from dataentry forms they shouldn’t be the same. A dataentry screen contains dataentryforms. And there shouldn’t be any object called dataentryScreen but only dataentryForm. Dataentry screen is more of a presentation and something to be implemented using action classes at the web layer.
When you have a dataset having dataelements with different category combos then difficult to display them using a single table. So what I am suggesting is to group these dataelements (those having the same catcombo) and create them dataentryform… like this a dataset can have have multiple dataentry forms. DataEntry form is to have a group of dataelements all sharing same categorycombo. Finally the dataset is free to have a set of dataforms, but only one dataentryscreen. I have attached you a sample form … we need to handle such a requirement.
You are saying one dataset say dataset1 can have multiple dataentry screens like dataentryscreen1,dataentryscreen2,dataentryscreen3.
When we select dataset1 in the dataentry module we should display these 3 screens for dataentry?
These 3 screens can have same dataelements or different dataelements?
On Wed, Dec 9, 2009 at 9:53 PM, Abyot Gizaw abyota@gmail.com wrote:
and also assigning multiple forms for datasets or programstages. For example a dataset might have dataelements having different categorycombos… for such cases it makes sense to group those datalements having the same categorycombo together then create a form… in the end such datasets will have a set of forms. So when displaying the dataentry screen we can display a list of forms and come up a nice looking dataentry screen.
Regarding DataEntryScreen, as we (Abyot & Me) discussed on his last visit we agreed to make CustomDataEntryScreen as Genric.
For that what we started is:
We changed DataEntryForm object to contain its id, name and html code only. (before it was bound with datasetid).
All the CustomScreen associations we kept in another table dataentryformassociation which contains associationtablename( represents which object DataSet/ProgramStage etc), associationid ( represents datasetid/programstage id), dataentryformid.
From the GUI:
If you goto dataset screen there will be icon to design custom screen for dataset like before. only change is before it was saving in dataentryform table. now it will save the design in dataentryform table and association will be saved in dataentryformassociation table.
Similarly for ProgramState also we can design screens.
Breifly that is what we are doing regarding CustomScreens. Is it OK or any changes?
I am sorry, the message of that commit was missing some information.
I had some problem while committing the source. It was locked, and I tried to use the break-lock command many times and finally it worked. That is why I did not write the full commit message.
So, that commit include
Custom DataEntryForm design form for ProgramStage ( this is what the FCK editor is for ).
I Added class DataEntryFormAssociation. And yes Abyot, when I was creating that class, I also wanted to create another package for all the dataentryform things. But that was like just a few days I touch the dhis code and I did not want to change so much. I just tried to follow the old work flow. Please do not worry, after read your email, I changed it immediately ( really happy to do that ) . You will see it in the next commit.
Custom data entry screen for case ( patient ) . This is not completely done, I am still working on it.
The reason for this commit is to merge my local changes with your trunk. Because I have been coding for about two weeks on this module with my local source code, not on any branch…so it really need to be merged as soon as possible.
And actually , I have not been in the dhis2-devs@lists.launchpad.net util Abyot send me and Bharath the email. I have just subscribed to the list yesterday. I did not know about that mailing list. When you added me to the core-dev team, I looked for mailing list of this team, but I could not.
About Abyot 's question :
The other thing, if you remember we even talked about having a set of forms for datasets/programstages. Because sometimes you might have multiple tables/sections. Do you think you can include these things?
Sorry, I do not know about this… Please explain it again if you have time.
Thank you,
Thanks Viet for your reply… Don’t misunderstand, we’re happy to see u contributing and I’m exited to see the new code/functionality. Its just important that Abyot understands whats going on and gets the change to review things as he is leading the patient system work… Now that you have enlisted for the dev list that’s will be easier:-) Tell me if you there is other stuff u are wondering about.
I like your suggestion very much but want (again I know!) to suggest a slightly different slant. I tend to think of a form as being the composite thing (like a paper form which might even have a reference number - form ANC-B3). And that form might have different screens and/or sections. Rather than the screen having multiple forms. Just a matter of naming I know, but if we are going to refactor like this, we do need to think about what is the least confusing to users.
Otherwise I am fully behind the suggestion of subsetting by common categorycombos - it does make sense. Possibly we need to implement a getDataElementsByCategoryCombo() method on DataSet to make it easier to select appropriate dataelements.
What I wanted to say is - think of separating dataentry screens from dataentry forms they shouldn’t be the same. A dataentry screen contains dataentryforms. And there shouldn’t be any object called dataentryScreen but only dataentryForm. Dataentry screen is more of a presentation and something to be implemented using action classes at the web layer.
When you have a dataset having dataelements with different category combos then difficult to display them using a single table. So what I am suggesting is to group these dataelements (those having the same catcombo) and create them dataentryform… like this a dataset can have have multiple dataentry forms. DataEntry form is to have a group of dataelements all sharing same categorycombo. Finally the dataset is free to have a set of dataforms, but only one dataentryscreen. I have attached you a sample form … we need to handle such a requirement.
You are saying one dataset say dataset1 can have multiple dataentry screens like dataentryscreen1,dataentryscreen2,dataentryscreen3.
When we select dataset1 in the dataentry module we should display these 3 screens for dataentry?
These 3 screens can have same dataelements or different dataelements?
On Wed, Dec 9, 2009 at 9:53 PM, Abyot Gizaw abyota@gmail.com wrote:
and also assigning multiple forms for datasets or programstages. For example a dataset might have dataelements having different categorycombos… for such cases it makes sense to group those datalements having the same categorycombo together then create a form… in the end such datasets will have a set of forms. So when displaying the dataentry screen we can display a list of forms and come up a nice looking dataentry screen.
Regarding DataEntryScreen, as we (Abyot & Me) discussed on his last visit we agreed to make CustomDataEntryScreen as Genric.
For that what we started is:
We changed DataEntryForm object to contain its id, name and html code only. (before it was bound with datasetid).
All the CustomScreen associations we kept in another table dataentryformassociation which contains associationtablename( represents which object DataSet/ProgramStage etc), associationid ( represents datasetid/programstage id), dataentryformid.
From the GUI:
If you goto dataset screen there will be icon to design custom screen for dataset like before. only change is before it was saving in dataentryform table. now it will save the design in dataentryform table and association will be saved in dataentryformassociation table.
Similarly for ProgramState also we can design screens.
Breifly that is what we are doing regarding CustomScreens. Is it OK or any changes?
I am sorry, the message of that commit was missing some information.
I had some problem while committing the source. It was locked, and I tried to use the break-lock command many times and finally it worked. That is why I did not write the full commit message.
So, that commit include
Custom DataEntryForm design form for ProgramStage ( this is what the FCK editor is for ).
I Added class DataEntryFormAssociation. And yes Abyot, when I was creating that class, I also wanted to create another package for all the dataentryform things. But that was like just a few days I touch the dhis code and I did not want to change so much. I just tried to follow the old work flow. Please do not worry, after read your email, I changed it immediately ( really happy to do that ) . You will see it in the next commit.
Custom data entry screen for case ( patient ) . This is not completely done, I am still working on it.
The reason for this commit is to merge my local changes with your trunk. Because I have been coding for about two weeks on this module with my local source code, not on any branch…so it really need to be merged as soon as possible.
And actually , I have not been in the dhis2-devs@lists.launchpad.net util Abyot send me and Bharath the email. I have just subscribed to the list yesterday. I did not know about that mailing list. When you added me to the core-dev team, I looked for mailing list of this team, but I could not.
About Abyot 's question :
The other thing, if you remember we even talked about having a set of forms for datasets/programstages. Because sometimes you might have multiple tables/sections. Do you think you can include these things?
Sorry, I do not know about this… Please explain it again if you have time.
Thank you,
Thanks Viet for your reply… Don’t misunderstand, we’re happy to see u contributing and I’m exited to see the new code/functionality. Its just important that Abyot understands whats going on and gets the change to review things as he is leading the patient system work… Now that you have enlisted for the dev list that’s will be easier:-) Tell me if you there is other stuff u are wondering about.
) . You will see it in the next commit.