Hi, Am 16.11.2012 um 14:37 schrieb Carsten Ziegeler:
> 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? Hmm, why not ? Regards Felix > > 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]
