----- Original Message ----- > From: "Jirka Tomasek" <[email protected]> > To: [email protected] > 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
