Re: [dhis2] The design of dhis2

[<kn...@ya...>]

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.

> 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?

> 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? 

> 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