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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
