RFC: Portlets for Conductor

Jason Guiditta jguiditt at redhat.com
Mon Oct 22 14:09:25 UTC 2012


On 19/10/12 12:57 -0400, Hugh Brock wrote:
>On Fri, Oct 19, 2012 at 09:48:13AM -0400, Tzu-Mainn Chen wrote:
>>
>>
>> ----- Original Message -----
>> > From: "Jirka Tomasek" <jtomasek at redhat.com>
>> > To: aeolus-devel at lists.fedorahosted.org
>> > Sent: Friday, October 19, 2012 4:35:23 AM
>> > Subject: Re: RFC: Portlets for Conductor
>> >
>> > On 10/19/2012 10:18 AM, Jiří Stránský wrote:
>> > > On 15.10.2012 16:33, Tzu-Mainn Chen wrote:
>> > >> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Portlets
>> > >>
>> > >> Please send any feedback you may have!
>> > >>
>> > >> Thanks,
>> > >> Tzu-Mainn Chen
>> > >>
>> > >
>> > > Hi guys,
>> > >
>> > > I'd recommend looking at Cells [1] and thinking if we can use it to
>> > > implement the portlets. It's a components/portlets implementation
>> > > for
>> > > Rails, has more than 1200 stars on GitHub [2], so I guess it's the
>> > > Rails "standard" for doing these things (although I admit I never
>> > > used
>> > > component based approach for views in Rails). It might prevent us
>> > > from
>> > > reinventing the wheel and also keep the project community-friendly,
>> > > as
>> > > I think it's always better to go with "standard implementations",
>> > > so
>> > > that community contributors are not forced to learn Aeolus-specific
>> > > solutions to standard problems.
>> > >
>> > > That said, I didn't look into this in detail, so I'm not sure
>> > > whether
>> > > Cells would fit for our use case. Just want to bring it up to your
>> > > attention.
>> > >
>> > > Have a nice day
>> > >
>> > > J.
>> > >
>> > > [1] http://cells.rubyforge.org/
>> > > [2] https://github.com/apotonick/cells
>> >
>> > This looks like exactly what we need. Anyway we might still consider
>> > whether a dashboard's controller (UsersController) can hold the
>> > amount
>> > of logic for portlets. It depends on the amount of portlets we want
>> > to
>> > use and logic necessary to generate data for them. If the amount is
>> > overkill for UsersController, I see the Cells as great solution. Only
>> > disadvantage I see is that it brings another gem dependency.
>> >
>> > Jirka
>> >
>>
>> Cells does look great, thanks for pointing it out!  From what I understand, a cell could represent a portlet or (in my grand vision) a portlet type; it's pretty arbitrary in that sense.
>
>+1 to using stuff that's already upstream (and contributing back to it
>if necessary) where we can...
>
>--H

Yes, I have been hearing about cells for a while, though I never
looked that close since I generally don't touch the ui.  I just took
a quick glance at the overview page, and they certainly look like a
good for a lot of the 'portlet' type stuff that conductor tends to
have a need for.  I would like to point out that these seem fairly
well in line with the design pattern of decorators/presenters, which
there was an interetsing talk on at railsconf[1].  The Cells library 
may be able to be used in concert with some of these patterns, if they
are not already baked in.  Also, this would be a good step in the
direction of decoupling components of the app.  Even though as a group
we have not yet been able to agree on all the details there, I think
the majority of people realize we need to make this thing more
modular.

-j

[1]
http://www.confreaks.com/videos/884-railsconf2012-presenters-and-decorators-a-code-tour



More information about the aeolus-devel mailing list