13 May
2009
13 May
'09
9:37 a.m.
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
13 May
13 May
10:29 p.m.
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).
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
15 May
15 May
11:33 a.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6047
days inactive
6049
days old
2 comments
2 participants
participants (2)
-
Jerome Velociter -
Vincent Massol