Re: [dhis2] The design of dhis2

[<ni...@if...>]

I am sorry for this late answer, I have been busy preparing for a
presentation we had for the health authorities in Tigray,
Ethiopia. Luckily they have accepted our implementation proposal.

> Thanks for starting to use this list! I am a bit concerned that things
> seem to be sent twice - is that something you could look into, Ola?
>
> --- ni...@if... skrev: > I have been reading in the recently
> published book {J2EE Development
>> without EJB}. It promotes the strategy we are planning to use, namely
>> using a lightweight framework for our business layer. This will
>> reduce
>> complexity compared to using EJB. This strategy work best for
>> web application, and I would thing for our application as well. But I
>> think we must keep in mind that we are not firstly developing a web
>> application, but that web enabling comes as an added value.
>
> Yes, you are right. But do bear in mind that developing two versions is
> quite costly. There are several alternatives for user interface, see
> http://jdhis.sourceforge.net/pmwiki/pmwiki.php/Development/UserInterface
>
> However, if we do work with Spring, it also has a rich client project
> http://www.springframework.org/spring-rcp.html.

I think it would be possible to use a standard gui like swing for the
part of the system that roughly are going to replace the AccessMD. And
www gui for the AccessRG (Report Generator) part. Then you would have
only one version of the UI layer for each module. But I understands
that it require a god deal extra effort to do so. You have to make a
remoteing layer, and a client.

>> The case of doing data entry is not well supported by a web
>> interface, and this comes to many managing and adapting cases as
>> well.
>
> You may very well be right in this, but it would be good to have some
> details saying exactly why it is not sufficient. With moderate client
> side scripting (i.e. javascript), things can be made quite nice. I
> agree that it is not ideal, and that some things are much easier done
> in a traditional interface, but we have to weigh the costs of
> developing two versions of the user interface. In any case, it seems
> likely that one of them should be developed first.
>
>>Common tasks is to add new data elements, fill inn lookup
>> tables, making a new organisational structure. This should be
>> supported by a more extensive UI than the web.
>
> Proabably  - but details, please. What exactly is needed and missing in
> a browser interface?

A browser interface is basically based on pages, with links in between
them. It is not in its nature very interactive. You can add some
interactivity with javascript. A problem with javascript as I have
experienced, is that different browser have different java script
implementations. In a traditional gui you can update only one
component on the screen. You can have a top menu, you can give user
the option to move frames in the gui to different position etc.

But all this said, I have had a look at Tapestry. I would think that
the javascripts that Tapestry use can be viewed with most
browsers. And with the functionality that Tapestry adds (as far as I
know), I have not seen anything in the existing AccessMD, that can not
more or less be replaced by Tapestry. Because Access I would say, is
like a web browser (or database browser), in the sense that you are
restricted by the environment and the data input forms used is much
like web input forms.
>
>> If a regional office have an intra net we need to have the business
>> layer remotely available. An other option is to have a shared
>> database, and have the business layer locally on each computer. But
>> there might be cases where there will be a need to have a shared
>> business layer.
>
> I belive we will have to limit our development efforts to two cases
> initially: One network/server based solution, with a web interface, and
> a standalone version. Then the question comes whether these have to
> differ. That then comes down to whether a browser interface will be
> sufficient. (Yet another option will be to run a rich client using a
> Linux Terminal Server Project (LTSP) kind of network app).
>
>> In that case we need a remote interface to our
>> business layer. The book I mentioned states that EJB is the best
>> solution for remote interfacing if you are using RMI or IIOP. But
>> since we don't want to struggle with the complexity of EJB, and don't
>> want to use a commercial application server, this is not a good
>> option. There are however other alternatives like SOPE. SOPE is a xml
>> based remoteing protocol closely associated with the web. There might
>> be other alternatives as well, this needs to be looked closer into.
>
> I suppose you mean SOAP, http://www.w3schools.com/soap/default.asp. But
> I doubt this is the time to go into this kind of scenario, although it
> is very good to keep it in mind, and we should detail the kinds of
> likely user settings for the software. Maybe you could write up a page
> on the Wiki?
>
Yes I meant SOAP :)

>> We need to think about how the reporting from district and upward
>> could be accommodated by our application in the light of the varying
>> infrastructure in the third world. There must be multiple options
>> among others,paper based reporting, sending a diskette, sending
>> e-mails, automatic sending of all data made in a period of time (done
>> at night when the telephone system is in little use), input of
>> individual entries in a regional/national database etc.
>
> Indeed, this is not a new question, or one restricted to the new DHIS.
> HISP already has to deal with this (although paper based reporting is
> what we seek to replace).
>
>> An other question is how the district can get access to
>> regional/national data and to data from other districts. This can be
>> done by making the regional/national report UI available on the
>> WWW. To make the report UI of individual district available on the
>> WWW
>> is possible, but for most district this is not an option.
>
> Not exactly sure what you mean here, as long as the data (all data)
> gets reported, it can be made readily available on the net?
>
> Cheers,
> Knut

Greetings
Nils Fredrik