2012/11/16 Felix Meschberger <[email protected]>: > 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. >
Sounds like a good idea, could printers override the category by setting this property itself? Carsten > 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] > -- Carsten Ziegeler [email protected]
