For those who didn't catch this on the commit list...
In SVN revs 679058, 679288, 679301 I committed a few changes to make
it easier/faster to implement common CrUD (Create, Update, and Delete)
services. The basic patterns are demonstrated in the services.xml file
in the example component, and there are extensive comments in the Java
file that implements this service execution engine as well
(org.ofbiz.service.engine.EntityAutoEngine).
Basically just set the engine attribute to "entity-auto" and the
invoke attribute to "create", "update", or "delete".
The most complex one is the create operation, and there are 4
variations of depending on how many primary keys you have and on
whether or not each is defined as an IN or an OUT to identify a
primary sequenced ID, a primary sequenced ID with optional manual ID,
a secondary sequenced ID, or a full primary key coming in with no
sequencing.
The update does a few fancy tricks with statuses and will populate an
oldStatusId OUT attribute if one is defined in the service def. If a
serviceId is coming IN and it is different than the current value then
it will also check to see if there is a StatusValidChange record that
covers the change, otherwise you'll get an error.
This covers most of what is needed in CrUD operations, and I've done a
fair bit of testing, so feel free to start enjoying it and please let
me know if you run into any issues, or you can think of other common
patterns we can identify based on the service definition and such to
cover more existing services then please let me know.
Also, if anyone feels the desire feel free to review existing services
that use the common patterns (documented in the
org.ofbiz.service.engine.EntityAutoEngine.java file) and get rid of
them and just use the engine="entity-auto" attribute.
================
On a related note: this is something I've debated for or against using
for a long time and finally decided that we might as well. Most of the
custom additional stuff we want to add to services using these common
patterns can be called through SECA rules. Anything we do lots of
times, we might as well add to the entity-auto implementation.
My original thought on this is that it would be easier to customize if
we had a simple-method for each of these that could be easily changed,
and because in spite of requiring additional initial effort the
ongoing maintenance would be easier we would see a net reduction in
effort because of the pattern.
I'm not so convinced of this now, so here's the new tool...
================
On another related note: I would like to look for other things that we
end up doing over and over and re-evaluate whether or not it is really
worth it, or if we should create something like this that covers our
common patterns and reduces the amount of code we have to write and
maintain.
-David