[katello-devel] Apipie and validation.

[Dmitri Dolguikh]

On 05/12/12 09:51 AM, Ivan Necas wrote:
>> [1] - https://github.com/Pajk/apipie-rails/issues/67
>>
>> ## Other notes
>>
>>   > The second issue is that apipie validations are stricter than AR
>> ones: array validation assumes that there's an array in place, while
>> AR
>> would accept a nil. These two combined lead to even more false
>> positives
>> during apipie validation.
> There is :allow_nil option, that lets you do this.

There is. But again, this is duplication.
-d


>
>> On 04.12.12 22:47, Ivan Necas wrote:
>>>
>>> ----- Original Message -----
>>>> On Tue 04 Dec 2012 05:10:28 AM MST, Dmitri Dolguikh wrote:
>>>>> On 03/12/12 09:36 AM, Lukas Zapletal wrote:
>>>>>>> Step #1 - let's get rid of controller validations.
>>>>>> Again, you can only do this for CRUD actions in the controllers.
>>>>>> For all
>>>>>> other methods we need validations. And we have those, not all
>>>>>> our
>>>>>> controllers are plain REST-driven. We do have procedure-like
>>>>>> actions.
>>>>>> Maybe more then we should have, but this is a fact.
>>>>>>
>>>>>> You say all the validations should be done in models, thus you
>>>>>> essentially say let's put all our code logic there. Because it
>>>>>> does not
>>>>>> make sense to do validations in models while doing anything else
>>>>>> (that
>>>>>> also requires some level of validations) in controllers or a
>>>>>> logic
>>>>>> layer. A fact: you need to do validations also outside of
>>>>>> models.
>>>>> Domain logic belongs in the model layer. We can discuss how to
>>>>> better
>>>>> factor model layer code, but not where to put it.
>>>>>
>>>>> -d
>>>>>
>>>>> A lot of rationalizations to keep validations in apipie have been
>>>>> put
>>>>> forward, *all* of them attempting to deal with various smells,
>>>>> code
>>>>> or
>>>>> process ones. Let's fix the root issues.
>>>>>
>>>>> Again, Let's get rid of validations in apipie. Refactor the
>>>>> controllers when needed. If apipie is not useful without those
>>>>> validations, let's suspend/stop use of it.
>>> Am I reading it correctly you suggesting getting rid of API
>>> documentation?
>>>
>>> -- Ivan
>>>
>>>>> -d
>>>>>
>>>> +1
>>>>>> It is wrong to put all your code logic into models. And
>>>>>> unfortunately we
>>>>>> have most of it there. Rails follows MVC pattern and what we
>>>>>> have
>>>>>> is
>>>>>> those
>>>>>> messy Models-for-everything approach. If you mix this with our
>>>>>> orchestration, it is deadly combination. Difficult testability,
>>>>>> huge
>>>>>> objects with no responsibility split, unable to mock things and
>>>>>> so
>>>>>> on.
>>>>>> Code logic in models works well for small projects and it is
>>>>>> de-facto
>>>>>> standard in Rails world. People just blindly follow this wrong
>>>>>> pattern.
>>>>>>
>>>>>> So I don't agree with this simplification you offer. We will
>>>>>> likely
>>>>>> start to refactor our orchestration creating new layer of code
>>>>>> logic,
>>>>>> which is the right approach to do things. And we should move
>>>>>> complex
>>>>>> methods like activation key subscription from models there. Then
>>>>>> we will
>>>>>> need validations on the controller side (or on the newly created
>>>>>> logic
>>>>>> layer or orchestration layer - depends on how are we gonna name
>>>>>> it).
>>>>>>
>>>>>> So yes, it has something to do with REST. My counter proposal
>>>>>> is:
>>>>>>
>>>>>> #2 Let's get rid of validations where they duplicate model
>>>>>> validators,
>>>>>> but let's keep them for (usually non-CRUD) methods which need
>>>>>> then. We
>>>>>> will likely be extending those soon.
>>>>>>
>>>>> _______________________________________________
>>>>> katello-devel mailing list
>>>>> katello-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>
>>>>
>>>> --
>>>> Jason E. Rist
>>>> Senior Software Engineer
>>>> Systems Management and Cloud Enablement
>>>> Red Hat, Inc.
>>>> +1.919.754.4048
>>>> Freenode: jrist
>>>> github/identi.ca: knowncitizen
>>>>
>>>> _______________________________________________
>>>> katello-devel mailing list
>>>> katello-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>
>>> _______________________________________________
>>> katello-devel mailing list
>>> katello-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel