16 May
2010
16 May
'10
9:29 a.m.
On May 16, 2010, at 1:28 AM, Thomas Mortagne wrote:
On Sat, May 15, 2010 at 17:01, Vincent Massol
<vincent(a)massol.net> wrote:
I guess my only question is: have you thought enough about doing it with one event and how
long it would take to do it right vs the "bridged" way?
Sometimes we choose a wrong solution simply because we think the right solution is too
costly whereas it's not the case in reality.
I haven't really thought about what it would take to do it right which is why I'm
asking.
Could someone list the steps to do it right?
Thanks
-Vincent
On May 15, 2010, at 4:53 PM, Jerome Velociter wrote:
Hi Devs,
I'd like to add a bridge event to allow components to get notified when
old core has been initialized (at the end of XWiki#initXWiki for
example).
This would be useful for components that needs to access the store, for
example to register XWiki classes.
I recognize this solution is not perfect since it's more bridged code,
but
it would be better that what we have been doing
so far (hard-coded
component initialization in XWiki.java, for example for the wiki macro
bridge to register its classes)
I've attached a patch proposal to
http://jira.xwiki.org/jira/browse/XWIKI-5194.
Note that I would also fix the wiki macro bridge initialization.
+1 from me to go ahead with that.
WDYT ?
Before I can answer, some questions:
- Why do you call it a "bridge event"?
- How would you call the event (I haven't checked the patch yet), knowing
that we already have an app initialized event?
- Do we need 2 events: app initialized + this one or is one enough?
- Why don't we initialize the store upon application start as the first
listener (we'll need an init order but we've been needing that anyway IMO)?
If we can have only a single app initialized
event it would be better IMO.
Yep, that's why Jerome propose it as a bridge.
That's the bit longer term goal but not sure it's that easy to do, at least
i think i would take too much time for anyone right now so the bridge event
Jerome propose is well enough in short term to clean up a little what we
already have for wiki macros and what he needs for wiki components.