Merge / split controller for UI and API?

Mo Morsi mmorsi at redhat.com
Mon Mar 26 16:49:19 UTC 2012


On 03/26/2012 11:00 AM, Scott Seago wrote:
> On 03/26/2012 10:54 AM, Petr Blaho wrote:
>> Hi all,
>>
>> I am now working on preparing API for Provider and ProviderAccount
>> resources
>> so I want to ask some questions regarding controllers for API.
>>
>> At this moment there are some controllers in API namespace and so
>> there is duplicated functionality between UI and API parts.
>>
>> In the future we will be adding features to API and CLI tool too.
>>
>> I think that we need to decide wheter keep UI and API controllers
>> separated or merge them together.
>>
>> I think that best will be to merge them together.
>> Controller should be as skinny as possible with minimum logic
>> (parameters sanitizing, model call, render results - view or whatever).
>> Controller should respond to html, js, json, xml, etc...
>> All the logic now present in controllers should be moved to models or
>> some other classes which will work with models (delegators,
>> decorators, name it...)
>>
>> Please, write your thoughts and/or experience with this kind of problem.
>>
> Hi Petr,
>
> I agree with your assessment here. In fact, that's how we started the
> initial API code -- the API return just uses the json or xml response
> of the same controller action that uses html or js for regular UI
> actions. I don't know exactly how we ended up taking a different path
> with images (I didn't work on that code), but it needs to be merged
> back into the main controllers.
>
> However -- we'll need to be careful with sequencing and deps, since
> the whole image back-end is being rewritten in another task, so I
> wouldn't want to merge the current image controller code. That should
> be done either as part of the image backend redesign or after it.
>
> Scott
>

Also agree with emphasis on keeping the controllers as minimal as
possible, dispatching to underlying subsystems (such as the service
layer, etc).

Actually what are people's thoughts about eventually (prolly alot
further on down the road) extracting some of these conductor subsystems
into their own locally invocable modules / gems. So that end users can
get some of the orchestration features without requiring the web
interface? Of course the web interface could still be build ontop of
this and be the default option for installing / using the entire
application.

  -Mo




More information about the aeolus-devel mailing list