----- Original Message -----
From: "Jirka Tomasek" <jtomasek(a)redhat.com>
To: aeolus-devel(a)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