7 Dec
2010
7 Dec
'10
12:02 p.m.
OK makes sense now.
I'll investigate that bridge. Should be possible with an aspect I think (you
can define pointcuts that catches constructor calls with aspectj) - but
maybe that's not the best solution.
Jerome.
On Tue, Dec 7, 2010 at 11:50 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Tue, Dec 7, 2010 at 11:24, Jerome Velociter
<jerome(a)xwiki.com> wrote:
Old events OK, but new bridge events should rather go in bridge module no ?
On Tue, Dec 7, 2010 at 10:49 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Tue, Dec 7, 2010 at 10:03, Jerome Velociter <jerome(a)xwiki.com>
wrote:
> > On Mon, Dec 6, 2010 at 3:40 PM, Thomas
Mortagne
> > <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >
> >> On Sun, Dec 5, 2010 at 15:20, Jerome Velociter <jerome(a)xwiki.com>
> wrote:
> >> > Hi devs,
> >> >
> >> > This is a buy one, get two proposal.
> >> >
> >> > I propose that first we rename DocumentUpdateEvent and
> >> > DocumentSaveEvent to respectively DocumentUpdatedEvent and
> >> > DocumentCreatedEvent. Which would be both more clear and would
comply
> >> > to the naming rules we've
agreed on (see
> >> > http://xwiki.markmail.org/thread/frzfzookl2lstsfj ). By rename I
> don't
> >> > mean real rename, but deprecation of the old events and creation of
> >> > two new ones.
> >> >
> >> > Then I propose we introduce two new events : DocumentCreatingEvent
and
> >> > DocumentUpdatingEvent, that
would be fired before the actual save.
> >> > This is a pretty common use case for code that needs to hook on
save
> >> > to perform any kind of
verification/pre-computation/etc. This is
the
> >> > same idea as the
"preverify" method of the legacy notification
> >> > mechanism. The events would actually be fired from the same place
as
> >> > the preverify method in old
XWiki.java.
> >> >
> >> > WDYT ?
> >> >
> >> > I'm +1 and if we agree I volunteer to make those changes on 3.0
branch
> >> > - and maybe the 2.7 too if we
agree we want that too (I do).
> >> > _______________________________________________
> >> > devs mailing list
> >> > devs(a)xwiki.org
> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >> >
> >>
> >> -0 if you do only that ;)
> >>
> >
> > Fair enough :)
> >
> >
> >> If you start refactoring theses events it would be a good idea to
also:
> >> - move them to bridge module (we
can't move them to model module
since
> theses events still send XWikiContext and
XWikiDocument)
> - refactor them to be based on references instead of strings
>
OK.
One more question : are you guys OK to maintain compatibility for the
events
to be deprecated in an aspect ?
(+1 from me)
Aspect I don't know but we need to have something listening to new
events and generating old events (not sure what is doable with an
aspect).
Also I think old events and bridge I described should be moved in some
"xwiki-legacy" module or something like that to clean up observation
module.
Or am I misunderstanding something ?
What I called "bridge" here is the component listening to new events
and generating old events. This component should go in "xwiki-legacy"
since it only make sense if you have old events.
As I said new events should go in core-bridge module.
Jerome.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
That way components already built will work
inside XWiki but
will need to be refactored when core dependency is upgraded.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Jerome.
>
> --
> Thomas Mortagne
> _______________________________________________
> 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs