On Tue, Dec 7, 2010 at 12:02, Jerome Velociter <[email protected]> wrote:
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.
My POV is that if we have a separated xwiki-legacy module there is no need to do an aspect, it's a lot easier to simply write a java component.
Jerome.
On Tue, Dec 7, 2010 at 11:50 AM, Thomas Mortagne <[email protected]>wrote:
On Tue, Dec 7, 2010 at 11:24, Jerome Velociter <[email protected]> wrote:
On Tue, Dec 7, 2010 at 10:49 AM, Thomas Mortagne <[email protected]>wrote:
On Tue, Dec 7, 2010 at 10:03, Jerome Velociter <[email protected]> wrote:
On Mon, Dec 6, 2010 at 3:40 PM, Thomas Mortagne <[email protected]>wrote:
On Sun, Dec 5, 2010 at 15:20, Jerome Velociter <[email protected]> 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 > [email protected] > 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.
Old events OK, but new bridge events should rather go in bridge module no ?
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.
That way components already built will work inside XWiki but will need to be refactored when core dependency is upgraded.
Jerome.
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne