[katello-devel] Foreman-api

[Dmitri Dolguikh]

On 28/08/12 01:54 PM, Chris Alfonso wrote:
> On 28/08/12 10:29 +0100, Dmitri Dolguikh wrote:
>> On 27/08/12 01:15 PM, Lukas Zapletal wrote:
>>> On Mon, Aug 27, 2012 at 01:07:14PM +0200, Miroslav Suchy wrote:
>>>> On 08/27/2012 11:27 AM, Ivan Nečas wrote:
>>>>> 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 
>>>>>
>>>>>
>>>> +1
>>>> [2] is much more readable to me.
>>> +1 No more "dynamic" stuff please.
>>
>> I don't want to get into discussion about code generation. We are 
>> developing within constraints and using conventions of REST and 
>> Rails. We should only write code when we are dealing with something 
>> that doesn't follow conventions, or extends them, instead of 
>> repeating the obvious.
>>
>> -d
> It wasn't clear to me that some attributes were not allowed on an update
> until I read server logs in the traceback either.  I'm going to add the
> disallowed attributes to the documentation for the client gem in this 
> case.
> Perhaps I should override the update_attributes method to raise an 
> exception
> if the developer tries to update a certain attribute. 

This bit is already handled by the server, I don't think you need to add 
an additional validation. I'd just make the filtering out of attributes 
somewhere closer to the model (not sure how Conductor keeps track of 
remotely-stored attributes, but somewhere in that general area of the 
code-base).

-d

> That might make more
> sense.
> -Chris
>>
>>>
>>> Plus your favourite IDE can OmniComplete :-)
>>>
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel