I would love to. Here are my first thoughts:
Add more events to IEventTopic to include something like "DOC_COMPLETE" in addition to the current "DOC_BEFORE_COMPLETE" and "DOC_AFTER_COMPLETE".
Use the "DOC_COMPLETE" as the hook to execute the business logic.
If we did use the ModelEvent as the framework to implement this change, then the plugin's OrderEventHandler.java would act as the controller to execute the correct class (ex. OrderCompleteIt.java or OrderPrepareIt.java).
I assume this change would also include refactoring the code to move all business logic out of the actual prepareIt() and completeIt() methods and into helper methods so that fragments could more easily override logic of a given method.
We also spoke at the castle about eventually breaking iDempiere into multiple repositories. Does this ticket touch this topic? Creating a feature as its own repository seems logical to me.
Is the vision to have a feature/plugin per table (C_Order, M_InOut, C_Invoice)? or one monolithic plugin for all model logic?
If you do not think that ModelEvent, what are your thoughts?
> Add more events to IEventTopic to include something like "DOC_COMPLETE"
I think the current BEFORE/AFTER events are enough if we can define the order of running the validators (eventhandlers) - does the service.ranking applies here?
> We also spoke at the castle about eventually breaking iDempiere into multiple repositories. Does this ticket touch this topic?
Probably we'll need to create a new repository for plugins - there are some tickets also talking about decoupling webstore and promotions (also jasper is a good candidate to decouple), but this plugin sounds too core - still haven't thought if it needs to be moved out, at the moment we just need to make it replaceable/extensible.
> Is the vision to have a feature/plugin per table (C_Order, M_InOut, C_Invoice)? or one monolithic plugin for all model logic?
IMHO it must not be per table, but maybe per functionality, but that's probably harder to achieve, let's try this as first step and proof of concept.
Therefore, i assume he ModelEvent is the preferred implementation method for now.
Here is how I plan to move forward:
create a fork of iDempiere
create a branch for this ticket
clean out MOrder prepareIt(), etc... methods
create a new plugin in the core with the package org.idempiere.business.order
update org.idempiere.business.order to implement ModelEvent
re-create order business logic in the new plugin using either the BEFORE or AFTER timing events (with special attention to service.ranking)
test and share
Please correct/fix as you deem appropriate. I anticipate having the first version for test around Nov 20th. Please let me know if this date causes any issues.
That's ok .
For the fork I recommend:
keep the fork just focused on this development - do not mix other tickets
keep the fork updated with main repo (pulling and merging frequently)