On Dec 19, 2011, at 16:00 PM, Bram de Kruijff wrote: > 2) Discussion on “Dashboard Plugin” > > This is a module is a generic JQuery plugin with some supporting demo > html/js files. Hence the name. It has nothing to do with open social > of gadgets. The only thing is that the opensocial dashboard > implementation uses this plugin. Some further notes: > > * The OpenSocial dashboard uses the dashboard plugin at the frontend (js) > * The Dashboard plugin reasons about widgets (“Generic UI concept”). > NOT to be confused with W3C widgets. > * The OpenSocial dashboard reasons about gadgets. Thus referred to as > widgets in some contexts and interfaces. > * The module contains wrong headers and minimizer stuff as Marcel > already mentioned in his input mail. (JIRA issues to be created)
Issues: 153 and 154. > It is confusing and widgets maybe a little overloaded term as it is > also used for W3C Widgets. With this scheme it is not unthinkable that > we will end up with methods called getWidgets() that return Gadgets > mixed in with Gadgets... if you catch my drift. It seems it would make > sense to at least confine the widget reference to the JQuery plugin. I think the fact that we just happen to use some code that uses the overloaded term widgets does not mean that now that we embed that code, we cannot change it. I propose we remove all references to "widgets" and just call them "gadgets" everywhere. Issue 155. > 3) Discussion on Gadget Management > > The current Gadget Management is not a clean whiteboard style as it > uses both whiteboard services and an embedded persistent store. This > is considered an undesirable implementation as it mixes/violates > patterns. The preferred way would be to (re)move persistence gadget > configuration to the other side and let that component publish > services as well. (JIRA issues to be created) Issue 156. > Gadget categories are implemented in a strange way. The provider > whiteboard services return POJOs with meta-data instead of providing > it directly and possibly and preferably through the service registry. > For example GadgetDefinition has it's own ranking and GadgetCategory > is a simple id/name pojo. Issue 157, 158. > Q: Why are Categories there at all? It is an arbitrary concept now > hardcoded/wired into gadget-management. Long discussion followed about > (not) making or forcing implementation choices onto applications at > the platform level versus application defaults and ease of development > etc... no real consensus yet? However, a compromise can be found in a > more modular design AND implementation. So in this example categories > can be an optional high level feature addon implemented as such > allowing anyone to not use it. (JIRA issues to be created) Issue 159, 160. Issue 161 solves an outstanding issue in 146, related to role based access. > Actions: > > Marcel : Create JIRA issues for changes from analysis/discussion Other issues from my original mail: Multi tenancy: Issue 162, 163, 164. REST API split: Issue 165 (also linked to 156 as one part of the REST API is optional now). Profile related: Issue 166, 167, 168, 169. That's all folks! :) Greetings, Marcel PS: +1 for the summary you gave Bram _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
