dhis2-devs team mailing list archive

[Saptarshi Purkayastha <sunbiz@xxxxxxxxx>]

It's an well accepted pattern in data driven application (like ours),
validation should be done ideally at the model layer... and when I raised
the point of not doing it in JavaScript, I meant not doing that as default.
By default doing the validation in model layer and then second for better
UI, lesser server load and other benefits, doing the JavaScript
validation...

Doing it in web actions is somewhat doing it in the Controller, which is
what I originally meant as a bad design, where chances are we can/have gone
wrong.

---
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme

My Tech Blog:  http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE


2009/12/23 Viet Nguyen <phamquocviet@xxxxxxxxx>

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