RFC: Portlets for Conductor

Tzu-Mainn Chen tzumainn at redhat.com
Fri Oct 19 13:09:46 UTC 2012



----- Original Message -----
> From: "Jirka Tomasek" <jtomasek at redhat.com>
> To: aeolus-devel at lists.fedorahosted.org
> Sent: Thursday, October 18, 2012 11:25:59 AM
> Subject: Re: RFC: Portlets for Conductor
> 
> On 10/15/2012 04:33 PM, Tzu-Mainn Chen wrote:
> > Hi,
> >
> > Matt and I have come up with a design for creating portlets in
> > Conductor for use in dashboard and the like.  Here's a summary
> > design document:
> >
> > https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Portlets
> >
> > Please send any feedback you may have!
> >
> > Thanks,
> > Tzu-Mainn Chen
> 
> Hi,
> 
> Regarding the implementation, if I understand correctly, the
> display_count is a count of items the collection will include,
> so the _retrieve_data_ method should include .limit(display_count)
> and
> then the rendered partial called in _display_ method
> would include :locals => {:collection => @collection} instead of
> :display_count. Is that right?
> 
> Also for me the initialize method params seem to be quite
> straighforward
> here as the collection might not always be based on one Model (Class
> name)
> Does this mean that the given PortletType would strictly define how
> the
> collection would be collected? I am getting the feeling that we
> would end up with different PortletType every time we'd want to use
> some
> portlet.
> 
> IMO what we need to render the Portlet is the partial which would
> define
> the structure and then the collection which is used to build it
> (passed
> as a local)
> So the partials would define the portlet type and the data needed
> would
> get passed from the controller. Putting the logic into separate
> Module seems to me as quite overkill, considering that we'll have 4-6
> different portlets (made using say 3 different partials) in the
> Dashboard.
> With the Portlet types we'd end up having 4-6 different PortletTypes
> each rendered once, each with specific retrieve_data method.
> 
> Of course we can create helper for view, just to call
> render_portlet(partial_name, data_collection) for simplifying the
> call
> in the view.
> 
> I aggree to use the model method or Module for retrieving the data
> collection to not to clutter the controller if the logic for
> retrieving
> the data would be
> more than few lines.
> 
> Jirka
> 

Hi,

Thanks for the feedback!

Part of the concept behind Portlets *is* the idea that the majority of portlets can be rendered using a few portlet types.  This may seem overly optimistic, but I think it's true.  A list type portlet that displays entities associated with a given user; and an administrative-type portlet that displays "hot" entities feels like it covers almost most cases.  Using PortletTypes to implement these ensures a consistency of logic and look-and-feel; in the longer term, it enables advanced features like individualized dashboards that users can modify without requiring developers to implement new portlets.

Regarding the logic for retrieving the data collection - I agree that it's quite basic for the list portlet types, but I anticipate it becoming more complex for other portlet types.

Thanks,
Tzu-Mainn Chen



More information about the aeolus-devel mailing list