felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [WebConsole] Categories for plugins
Date Fri, 16 Nov 2012 13:37:21 GMT
2012/11/16 Felix Meschberger <fmeschbe@adobe.com>:
> 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 <fmeschbe@adobe.com>:
>>> 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
>> cziegeler@apache.org
>



-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message