dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

You have a good point, and as long as people are using the controller layer
as it stands (java) then we are OK. However, I think Bobs point is that if
different controller layers are swapped out, lets assume perhaps with a
simple Java mobile client, we would  have to adapt the controller layer to
these new clients. Perhaps a totally different controller layer would be
used, like Ruby or  something totally different.    I keep dreaming of an
ncurses  client for terminal data entry, but then perhaps I just really
antiquated, and this does not really seem to be on the roadmap for DHIS2.

Being an SQL guy, I am quite biased admittedly. I have argued, rather
quietly, for more logic and procedures to be placed in the DB, but I realize
one of the fundamental design principles of DHIS2 is to be able to be
portable between DB systems. This obviously necessitates the need to place
the validation in the control and/or view layers. Validation, like stored
procedures, are typically not very transportable between DB systems.

Anyway, I think you raise good points.

Best regards,
JPP


On Wed, Dec 23, 2009 at 6:04 PM, Viet Nguyen <phamquocviet@xxxxxxxxx> wrote:

> Hi,
>
> I don't think a validation in model layer is a good idea. Because a
> validator have to throw back to the view layer the error messages. If we
> validate at model layer, then for validating, a parameter have to go from
> view layer, through the controller to the model layer. Then if there would
> be error, the messages will be throw back through 2 layers. I think its not
> good for the framework.
>
> From what I have been doing with my spring mvc project. I have some ideas
> for this problem :
>
>    - Create a custom action called "EntityAction" that can handle Add,
>    Update and delete actions for one entity.
>    - Validation can be a method of the action class or a separate class,
>    but it should not be an action. It will be called right after the action
>    accepting the request. Then only if the validation is success the action
>    will call the corresponding method which can be add, update, delete or
>    execute. If there is error, we can return the same view file include all the
>    values of the parameter that were accepted before and the error messages.
>    - For validating jobs, all the rules that are alidated at the view
>    layer by javascript, I always have to validate them again at the controller
>    layer. And I try to validate as much as I can at the view layer, because it
>    will make the view layer becomes more user-friendly.
>
> To apply those things, I think we will have many works to do, but they are
> doable.
>
> Hope this can help.
>
> regards,
>
>
>
> On Wed, Dec 23, 2009 at 6:44 PM, Jason Pickering <
> jason.p.pickering@xxxxxxxxx> wrote:
>
>> Well, usually this would be the case, that there would be validation at
>> the database level, but given the database agnostic nature of DHIS, I have
>> no idea how or if this can be done.  I would think that the period "
>> YYYY-MM-YY" value should actually be stored as a real date type. Currently,
>> I think it is only text. The same can be said for the datavalue table, which
>> stores values as text, instead of having a datavalue table with multiple
>> columns (one for integers, reals, booleans, text and so forth, similar to
>> DHIS 1.4) , each with real db data types. Of course, placing other
>> constraints at the db level is also possible, but have no idea how to do
>> this with hibernate.
>>
>>
>>
>> 2009/12/23 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>
>> 2009/12/23 Lars Helge Øverland <larshelge@xxxxxxxxx>
>>>
>>>
>>>>
>>>> On Wed, Dec 23, 2009 at 4:01 AM, Hieu Dang Duy <
>>>> hieu.hispvietnam@xxxxxxxxx> wrote:
>>>>
>>>>> Dear Saptarshi,
>>>>>
>>>>> I'm not good at about security, I also knew that using javascript it's
>>>>> really not safe in web application. By the way, I have a small idea about
>>>>> this issue that. Not surely, have any configuration/setting about date in
>>>>> DHIS2 program ? Unless, I think we can make a new setting for this one.
>>>>> I meant we should make a pattern setting for date format, ie.
>>>>> yyyy-mm-dd for DataEntry module. Or can be expanding to use for our whole
>>>>> system.
>>>>>
>>>>> In that case, we can easily use any kind of validations with that
>>>>> pattern setting in either client-side (javascript) or server-side (java).
>>>>>
>>>>> Thanks for your suggestion !
>>>>>
>>>>>
>>>> Hi,
>>>>
>>>> I would say that we should stick with yyyy-mm-dd for input for now, to
>>>> me the added complexity of configurable date input formats justifies the
>>>> benefit...
>>>>
>>>> Re validation, we do have server side validation for meta data like data
>>>> elements, indicators, data set etc. A problem is that we have separate
>>>> action classes for validation and adding/updating (this was done with
>>>> separation-of-concerns in mind). This poses a threat since a "malicious"
>>>> user could bypass this by turning off javascript in the browser or sending
>>>> direct GET-requests. Btw I wouldn't say avoiding javascript validation is
>>>> the answer, rather having both where its possible.
>>>>
>>>
>>> Agreed it is not an either/or thing.  Validation at the browser and
>>> validation at the server actually serve two different purposes.  Client side
>>> validation is really a convenience to the user to prevent having to enter
>>> data only to find that the data is later rejected after the http post/get.
>>> Catching the validation problem early allows for a slicker and more friendly
>>> user interface.  But because it can be easily bypassed it is not a mechanism
>>> for protecting the integrity of data to be persisted and should not be used
>>> with that in mind.  That is the purpose of server side validation.  But of
>>> course we all know that ....
>>>
>>> Sorry I haven't looked much at the validation action classes so I can't
>>> really comment much.  But shouldn't the validation be a function of the
>>> model layer (as low down as it can be pushed) and be "un-bypassable"?.  This
>>> way it also applies to data input from other sources than the web ui.
>>>
>>> Bob
>>>
>>>
>>>
>>>> Lars
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Nguyen Pham Hoang Quoc Viet
>
>