I am resurrecting the initial thread when the "entity-auto" engine was
implemented; this is a great addition but we could even push it at a further
level (again following the "configuration by exception" strategy):
why don't we make it optional the service definition for crud services?
The idea is that, if I call:
Map result = dispatcher.runSync("createExampleEntityName", UtilMisc.toMap(...));
and the system can't find a service definition for createExampleEntityName but
it finds an entity definition for "ExampleEntityName" then it calls the
"entity-auto" service for it.
Of course same applies to create/update/delete.
At that point, as soon as we define an entity we will also have automatically
the CRUD services.
Jacopo
On Jul 27, 2008, at 9:28 AM, David E Jones wrote:
>
> 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
>
>
>
