[katello-devel] Apipie and validation.

[Ivan Necas]

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