Hi Jerome, On May 13, 2009, at 10:29 PM, Jerome Velociter wrote:

Hi Vincent,

This sound good, I like the component manager events idea.

I have only one concern re- the macros, it's the ability to get a list of macros by "source". Let me draw the use case:

Let say I want to write a macro manager UI that would for example list all wiki macros, and provide links to edit them. Next to that I'd like to display another list, with all bundled java macros (not editable, but still acknowledge their existence and description, parameters, etc.). I could do that by deduction, find the editable macros querying their definition objects, but that's not a good solution. Later on I could want to add to that later list the macros offered by a distant server and display a specific icon next to them to inform that the macro availability depends on the connectivity with the remote server when loading macros, etc.

It's probably achievable with the component manager strategy, we have to find the right way to do so (IMO having that info offered by the macro interface is not very nice).

Re the rendering and macro system a macro is a macro, independently from how it was registered in the component system. So there's no way to differentiate them and it's a good thing (it's a feature). So it means that if you want to allow editing macros that are defined in wiki pages for example then you need to get that information elsewhere, from the list of wiki pages that are macros for example. Another (better?) idea is that for macros that you create dynamically from wiki pages you have them implement a WikiMacro tagging interface (or an annotation) so that when you get the list of macros you can verify if they are wiki macros. Thanks -Vincent

Jerome.

Vincent Massol wrote:

...

Hi,

I don't think we need different Macro Sources in the rendering module. All we need is a single source that takes its macros from the classloader.

What we do need are different modules that create Macro components so that they are made available to the single Macro Source.

For example the annotations are defining macros and their not a source. They don't need to be. All they have to do is call ComponentManager.registerComponent() to register new macros.

The same should be done for macros defined as wiki pages or macros defined in a remote repository. All we need are handlers that can extract information and generate calls to ComponentManager.registerComponent().

Now since we need to be performant we want to cache Macros at init time in the Macro manager but we also need to support macros added dynamically later on. For this I think we need to introduce Component Manager events (this already exists in Plexus BTW) that would allow listeners to get events when a component is created or disposed of. In this manner the Macro Manager would subscribe to CM events for the Macro.class role and be able to add/remove Macros on the fly.

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs