Hi, Am 16.11.2012 um 10:50 schrieb Carsten Ziegeler:
> Hi, > > sounds good to me - can we apply a similar approach to the > configuration printers? It's currently a pain to get to the > information of a printer which is not in the first set displayed. How about integrating configuration printers differently than today ? Today, we have the "Configuration Status" plugin which manages the printers. How about changing this like this: ConfigurationPrinter services with mode=web are internally registered as plugins with the category "Configuration Status" by wrapping in a ProxyPlugin similar to what we do for plugin services to support delayed loading. The ConfigurationPrinter plugin itself would just care for the TXT and ZIP download cases. WDYT ? Regards Felix > > Regards > Carsten > > 2012/11/16 Felix Meschberger <[email protected]>: >> Hi all, >> >> Over time more and more plugins will get installed into a WebConsole to >> extend system administration functionality. Each added plugin adds a button >> to the top navigation which leads to clutter once the number of plugins >> (buttons) grow. For example the current Apache Sling Launchpad setup of the >> Web Console has 21 plugins and our commercial application even has 31 >> buttons (with a growing tendency). >> >> So, I propose we do something about this ;-) >> >> Lets add plugin categories: This allows us to create a tree structure of >> links to the plugins. As for GUI we replace the current button list at the >> top of the display with a tree navigation to the left. The categories are >> the nodes of the tree and the plugins are the leafs of the tree. >> >> To implement we could do the following: >> >> * Plugins registered as services may have a "felix.webconsole.category" >> property indicating the category. Plugins not registering this property will >> be placed in the default category >> * AbstractWebConsolePlugin is ammended with a getCategory() method, which >> may overwritten by implementations. The default implementation in the >> AbstractWebConsolePlugin class returns the default category >> * A default category can be configured >> * Categories are simple strings such as "OSGi" or relative paths such as >> "Sling/Main". Relative paths define multi-level trees. I think in general a >> single level is probably enough. Maybe we can start with just supporting a >> single level (so just plain strings). >> * Translation of categories is such that each segment in the path (or the >> complete string if there is no sub-categories) is converted into a >> translation label by prefixing with "category.". So the translation for the >> "OSGi" category would be found with the translation string "category.OSGi". >> * The plugin navigation is refactored to move it to the left and render it >> as a tree structure (I assume we can use the JQuery treetable plugin). >> >> WDYT ? >> >> Regards >> Felix > > > > -- > Carsten Ziegeler > [email protected]
