Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
Having a long list is not a problem - didn’t mean that.
With the current line of discussion at some point a requirement asking to further section a section will popup - this is where my problem is. Because you wanted me to use sections, and I think sections were introduced to break a long and tedious dataentry screen into smaller pages, then grouping of dataelements based on categroycombos is going to be a section with a potential to have a long list of dataelements, then finally further splitting this into smaller sections will be the next question - this exactly my problem which I don’t have the answer right now. And that why I didn’t want to touch the section thing it might ask for a complete re-write.
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Ola
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
I opted for this because we already have all the information persisted - dataeleement and dataset. With the approach you are suggesting then we need to refactor the dataelement-dataset association into dataelement-section/form/xxxxxxx Bob can suggest a good name and section/form/xxxxx-dataset … are we ready to do that?
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Ola
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
I’ve quickly tested the multiple MD forms and they look great, good work. Some issues that I came across are:
how can I define the order of the Data Elements in the tables? and how did you order them? Could this use the system setting for ordering objects? Right now they are not even alphabetical which is my system setting. And they are not following the order of data elements in the edit data set selection list either. Could you do something similar here to what is used with catoptions with the green tabs up and down?
Tabbing doesn’t work well as the focus seems to randomly jump between fields of different tables
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
Abyot,
I’ve quickly tested the multiple MD forms and they look great, good work. Some issues that I came across are:
how can I define the order of the Data Elements in the tables? and how did you order them? Could this use the system setting for ordering objects? Right now they are not even alphabetical which is my system setting. And they are not following the order of data elements in the edit data set selection list either. Could you do something similar here to what is used with catoptions with the green tabs up and down?
The ordering yes I know it won’t work. Because the current ordering service works only with datasets and I need to clone that for collection of dataelements.
Tabbing doesn’t work well as the focus seems to randomly jump between fields of different tables
I will check the tab - I haven’t really tested this.
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
Abyot,
I’ve quickly tested the multiple MD forms and they look great, good work. Some issues that I came across are:
how can I define the order of the Data Elements in the tables? and how did you order them? Could this use the system setting for ordering objects? Right now they are not even alphabetical which is my system setting. And they are not following the order of data elements in the edit data set selection list either. Could you do something similar here to what is used with catoptions with the green tabs up and down?
The ordering yes I know it won’t work. Because the current ordering service works only with datasets and I need to clone that for collection of dataelements.
OK, so you will look into this? Would be good to have custom ordering to be able to mimic the paper forms.
Tabbing doesn’t work well as the focus seems to randomly jump between fields of different tables
I will check the tab - I haven’t really tested this.
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
I opted for this because we already have all the information persisted - dataeleement and dataset. With the approach you are suggesting then we need to refactor the dataelement-dataset association into dataelement-section/form/xxxxxxx Bob can suggest a good name and section/form/xxxxx-dataset … are we ready to do that?
I wouldn’t suggest doing that, let alone naming it! I don’t know how many times I have said this now, but I am uncomfortable using our data structure to determine how we lay out forms. But I see we already have done this to certain extent with DataSet sections so my advice to Ola was just use that as it is already there.
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Ola
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
Abyot,
I’ve quickly tested the multiple MD forms and they look great, good work. Some issues that I came across are:
how can I define the order of the Data Elements in the tables? and how did you order them? Could this use the system setting for ordering objects? Right now they are not even alphabetical which is my system setting. And they are not following the order of data elements in the edit data set selection list either. Could you do something similar here to what is used with catoptions with the green tabs up and down?
The ordering yes I know it won’t work. Because the current ordering service works only with datasets and I need to clone that for collection of dataelements.
OK, so you will look into this? Would be good to have custom ordering to be able to mimic the paper forms.
For now have settled for “User Setting” sorting mechanism. Since I am not using the section module, having a custom ordering will be a bit of a work especially if we want to do it through section GUI . But if the custom ordering is going to be through the dataset GUI then will try to do that. This will be like sorting the dataelements of a dataset all at once and then grouping them by category - I think it is ok to do it in such a way.
Tabbing doesn’t work well as the focus seems to randomly jump between fields of different tables
I will check the tab - I haven’t really tested this.
Having a long list is not a problem - didn’t mean that.
With the current line of discussion at some point a requirement asking to further section a section will popup - this is where my problem is. Because you wanted me to use sections, and I think sections were introduced to break a long and tedious dataentry screen into smaller pages, then grouping of dataelements based on categroycombos is going to be a section with a potential to have a long list of dataelements, then finally further splitting this into smaller sections will be the next question - this exactly my problem which I don’t have the answer right now. And that why I didn’t want to touch the section thing it might ask for a complete re-write.
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Ola
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
Thanks for linking back to that discussion. I think what have changed a little after that previous discussion is how we have used dataset sections to group data elements by catcombo in the Sierra Leone implementation. I am not 100% sure how Bob does it with sdmx export now, but the intention was that in stead of using datasets to define data values with the same dimensions we could use data set sections (since datasets can have multiple catcombos).
I know we have more long term plans to redo the whole data set - form model, but since that might be really long term I would really like to see some small quick fixes to the existing model to make that work while waiting for the new model to be ready.
So the question is, would the following changes be small enough to consider now, or should they just wait until they can be part of the new model:
Generate default forms based on dataset sections (and only one catcombo per section is allowed), and if no section then by catcombo.
Allow a custom sort order for data elements inside a section. Similar to how you can sort catoptions inside categories.
These two changes would make it a lot easier to use the default forms in stead of having to design custom forms for all datasets with more than one catcombo.
What do you think Abyot, would these 2 changes take a lot of time?
Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@who.int|Tel: +41 788216897
Having a long list is not a problem - didn’t mean that.
With the current line of discussion at some point a requirement asking to further section a section will popup - this is where my problem is. Because you wanted me to use sections, and I think sections were introduced to break a long and tedious dataentry screen into smaller pages, then grouping of dataelements based on categroycombos is going to be a section with a potential to have a long list of dataelements, then finally further splitting this into smaller sections will be the next question - this exactly my problem which I don’t have the answer right now. And that why I didn’t want to touch the section thing it might ask for a complete re-write.
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Ola
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
It might take a little time I guess. Because I am not exactly sure how the Section module works… my guess is we need to rewrite this module.
Since it is the long list of dataelements belonging to the same catcombo that is creating the problem, we need to do sectioning for dataelements of a catcombo not dataset.
I am a little busy these days, but will see if I can squeeze this into my schedule.
Abyot.
···
On Tue, Jan 19, 2010 at 1:18 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
Thanks for linking back to that discussion. I think what have changed a little after that previous discussion is how we have used dataset sections to group data elements by catcombo in the Sierra Leone implementation. I am not 100% sure how Bob does it with sdmx export now, but the intention was that in stead of using datasets to define data values with the same dimensions we could use data set sections (since datasets can have multiple catcombos).
I know we have more long term plans to redo the whole data set - form model, but since that might be really long term I would really like to see some small quick fixes to the existing model to make that work while waiting for the new model to be ready.
So the question is, would the following changes be small enough to consider now, or should they just wait until they can be part of the new model:
Generate default forms based on dataset sections (and only one catcombo per section is allowed), and if no section then by catcombo.
Allow a custom sort order for data elements inside a section. Similar to how you can sort catoptions inside categories.
These two changes would make it a lot easier to use the default forms in stead of having to design custom forms for all datasets with more than one catcombo.
What do you think Abyot, would these 2 changes take a lot of time?
Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@who.int|Tel: +41 788216897
Having a long list is not a problem - didn’t mean that.
With the current line of discussion at some point a requirement asking to further section a section will popup - this is where my problem is. Because you wanted me to use sections, and I think sections were introduced to break a long and tedious dataentry screen into smaller pages, then grouping of dataelements based on categroycombos is going to be a section with a potential to have a long list of dataelements, then finally further splitting this into smaller sections will be the next question - this exactly my problem which I don’t have the answer right now. And that why I didn’t want to touch the section thing it might ask for a complete re-write.
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Ola
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
Thanks for linking back to that discussion. I think what have changed a little after that previous discussion is how we have used dataset sections to group data elements by catcombo in the Sierra Leone implementation. I am not 100% sure how Bob does it with sdmx export now, but the intention was that in stead of using datasets to define data values with the same dimensions we could use data set sections (since datasets can have multiple catcombos).
So far I’ve only got a dataset with dataelements of the same categorycombo so haven’t had to confront the problem yet
Having said that, discussion on sdmx-hd last week seemed to reach the conclusion that we can combine “ragged” observations (ie of different categorycombo) in the same dataset, filling in the holes with something like “not-applicable”) Its fairly ugly but it does mean the section thing is not so critical from this perspective.
Otherwise I think the suggestion does sound good from the default form perspective though I worry that division into sections for the purpose of form layout shouldn’t necessarily be facilitated by having these sections in the model. Its the wrong place. The right place would be to ask the user to group and order them at the point of form generation. But as you say, that’s maybe a longer term prospect.
I know we have more long term plans to redo the whole data set - form model, but since that might be really long term I would really like to see some small quick fixes to the existing model to make that work while waiting for the new model to be ready.
So the question is, would the following changes be small enough to consider now, or should they just wait until they can be part of the new model:
Generate default forms based on dataset sections (and only one catcombo per section is allowed), and if no section then by catcombo.
Allow a custom sort order for data elements inside a section. Similar to how you can sort catoptions inside categories.
These two changes would make it a lot easier to use the default forms in stead of having to design custom forms for all datasets with more than one catcombo.
What do you think Abyot, would these 2 changes take a lot of time?
Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@who.int|Tel: +41 788216897
Having a long list is not a problem - didn’t mean that.
With the current line of discussion at some point a requirement asking to further section a section will popup - this is where my problem is. Because you wanted me to use sections, and I think sections were introduced to break a long and tedious dataentry screen into smaller pages, then grouping of dataelements based on categroycombos is going to be a section with a potential to have a long list of dataelements, then finally further splitting this into smaller sections will be the next question - this exactly my problem which I don’t have the answer right now. And that why I didn’t want to touch the section thing it might ask for a complete re-write.
Yes I have started looking at it. And I was thinking of writing a mail about it, but the commit was very late and went to bed
What I have done is
made 2 methods in dataElementService
method 1 takes collection of dataElements and returns a sorted collection of categoryCombos that the passed dataElements contain. The sorting is simple based on the number of optioncombos each categorycombo has.Say for example default categorycombos will appear first, then with 2 optioncombos, with 3 … it goes on. This will help to have a consistent look in the dataentry form
method 2 takes collection of dataElements and returns a mapped collection of dataelements. The mapping is Map<CategoryCombo, Collection>. My assumption is you can throw whatever dataElement in your dataset. And using this method then possible to filter/group the dataElements based on their categorycombo
in multidimensional dataentry
get the dataset
get collection dataelements for the selected dataset
use the 2 newly created methods and get the categorycombos
generate table heading for each categorycombo
populate the dataentry form using the table headers generated
under each table list the dataelements that belong to the corresponing tableheading/categorycombo
then of course dataentry
My next plan is to apply this for default dataset reports.
Thanks Abyot, this is exactly the kind of functionality I was asking for yesterday.
Seems you are dealing with this without any need for a new object to persists all data elements with the same catcombo, you just use a service to get that collection. I assume that if we look at the next steps, if you need to make some editing to a form section (table/catcombo part of a form) like custom heading, grey fields etc. then you need to persist that somehow?
The section thing … I haven’t looked into it - am not even sure what to do there. Because I thought the idea of sectioning was to break a long list of dataelements into smaller pieces.
As far as I know Vietnam has been the only place to use these sections and they developed it. I am not 100% what they are used for either.
Yes it should be possible to generate the sections automatically based on categorycombos, and while doing that we are not breaking into pieces but rather grouping based on categorycombos. My worry is while identifying a collection of dataelements belonging to the same categorycombo and call it a section, we might endup with a long list of dataelements. If a long list then we need to think of sectioning a section which is a bit complicated or else put some kind of assumption - like no more than 10 dataelements in a section !
I am not sure why the long list is a problem. Since we base this on catcombos we get the tables in the entry form as they would look on the paper report right, but that needs to be further split up? Where would it be a problem to have a long list of data elements? I assume that if we have non-dimensional data elements there would be no tables and then just a long list since they all belong to the same catcombo (default) and then automatically the same section? I guess it should be possible to put data elements from the same catcombo in two different sections as long as all data elements in one section share the same catcombo? Wouldn’t that solve the long list problem?
Ola
Are we using the section functionality by the way?
Hi Abyot, great that you are taking initiative on this. Could you explain a bit what you did, is this sorting out some of the short-term needs Ola wrote about in that last mail?
and section/form/xxxxx-dataset … are we ready to do that?