dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

As always there is not a single right and wrong answer here.  There are some
things (usually different things) that might need to be validated at
different levels of the application.  But things which might make a mess of
the model should be validated by the model (or the service layer as I see
Lars has just chiped in :-).  I'm not sure if I really buy the idea that
communication of problems at the model shouldn't percolate up to the UI.
Are we saying that from a UI perspective, an update, delete or add should
allows be assumed to just succeed?  Of course these will sometimes fail and
of course we have to feed that back up (whether by exception or return value
- whichever is least evil).

I just took a brief look at the new hibernate validator.
http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single/index.html.
I'm not a hbernate expert but I think it answers your question, Jason, on
how constraints can be applied in a db agnstic way.  I'm not sure how this
works in hibernate 3.2.6.

Cheers
Bob


2009/12/23 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
>>
>>
>
> _______________________________________________
> 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
>
>