[katello-devel] Foreman-api

[Dmitri Dolguikh]

On 27/08/12 10:27 AM, Ivan Nečas wrote:
> On 08/24/2012 04:58 PM, Dmitri Dolguikh wrote:
>> On 24/08/12 03:57 PM, Bryan Kearney wrote:
>>> On 08/24/2012 10:52 AM, Jason Rist wrote:
>>>> On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote:
>>>>> On 24/08/12 03:38 PM, Lukas Zapletal wrote:
>>>>>> On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote:
>>>>>>> Hey guys,
>>>>>>>
>>>>>>> I'm about to add api bindings for environments to Foreman API, but
>>>>>>> was wondering about the goals of that [sub]-project. In particular,
>>>>>>> why did we choose to create our own code instead of using Rails
>>>>>>> ActiveResource (did anyone looked if there are still issues with
>>>>>>> Oauth when using ActiveResource)? Another one is why do we perform
>>>>>>> client side validation of parameters?
>>>>>> The right question is maybe - why we started coding 
>>>>>> resource/pulp.rb and
>>>>>> resource/candlepin.rb huge files with all the methods there? ;-)
>>>>> They started small. It's pretty easy to break them up (we should) 
>>>>> - each
>>>>> file is a collection of classes corresponding to resources on
>>>>> pulp/candlepin server. I'd like to see if we can switch to
>>>>> ActiveResource though - perhaps it's viable now. Ohad - have you 
>>>>> looked
>>>>> at this lately?
>>>>>
>>>>> -d
>>>>>>
>>>>>> Any outcomes so far?
>>>>>>
>>>>>> LZ
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> katello-devel mailing list
>>>>> katello-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>
>>>>
>>>> OpenShift is primarily using ActiveResource.
>>>
>>> If I recall, ActiveResource assumes a rather rails centric json 
>>> view. It it works, rgeat. If not, you end up monkey patching alot.
>> Hmm. I remember issues with OAuth and not-very-restful urls (I don't 
>> remember any json issues though). Perhaps those have been solved/made 
>> manageable?
> What advantage does it bring us?
>
> ActiveResource works well only if you strictly follow the Rails 
> conventions. 
We are using rails, and are following Rest conventions most of the time 
(the rest of the cases should be fixed).
> Take an example from the client library for Katello based on 
> ActiveResources [1]. It doesn't work well (forcing you to do hacks), 
> because for security reasons, Katello does allow you only subset of 
> attributes. So from this code, I know nothing about what arguments I 
> can pass in (I see only arguments I can't update, which is quite 
> useless).
>
> If you take a look at the generated code [2] for Foreman, you 
> immediately see, how you can use that. No hacks needed. Another fact 
> is that this approach forces you to document you API. ActiveResource 
> without sufficient documentation of your API is unusable.
I'm not arguing about documentation.
>
> Me as a developer, I find it much easier to use the code that I 
> immediately see what it expects from me.
>
> [1] - 
> https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb
> [2] - 
> https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb

I'd argue that the attribute filtration doesn't belong in [1]. [2] has a 
lot of repetitive code, indeed that's the reason why you generate it, 
and why I don't like it. It makes more sense for non-standard methods, 
but index, show, update, create can either be moved into some common 
mixin, or be generated similarly to accessor generators.

-d

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