You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <jo...@hotwaxmedia.com> on 2008/07/27 09:28:37 UTC
The fancy new entity-auto service execution engine
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
Re: The fancy new entity-auto service execution engine
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
I was thinking to use another generic security check based on a naming convention (e.g. a security service with entity name and something).
Jacopo
On Mar 7, 2012, at 5:16 PM, Adrian Crum wrote:
> What permission checks would be performed?
>
> -Adrian
>
>
> On 3/7/2012 2:53 PM, Jacopo Cappellato wrote:
>> 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
>>
Re: The fancy new entity-auto service execution engine
Posted by Ruth Hoffman <rh...@aesolves.com>.
Interesting, but this sounds a bit dangerous to me.
How about a Utility that lets you check if an Entity exists at
all...instead of throwing nasty errors. Or am I still back in the dark
ages and this already exists in the trunk?
Thanks much for you attention to this.
Best Regards,
Ruth Hoffman
On 3/7/12 11:16 AM, Adrian Crum wrote:
> What permission checks would be performed?
>
> -Adrian
>
>
> On 3/7/2012 2:53 PM, Jacopo Cappellato wrote:
>> 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
>>
>
Re: The fancy new entity-auto service execution engine
Posted by Adrian Crum <ad...@sandglass-software.com>.
What permission checks would be performed?
-Adrian
On 3/7/2012 2:53 PM, Jacopo Cappellato wrote:
> 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
>
Re: The fancy new entity-auto service execution engine
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
>
>
>
Re: The fancy new entity-auto service execution engine
Posted by him_aeng <hi...@yahoo.co.th>.
how can use this in "master-detail" scenario such as create example's record
and so retrive that record's exampleId value to create a new exampleItem's
record that use this exampleId value.
It possible in minilang and I don't know to do this in "entity-auto"
feature.
thank you
--
View this message in context: http://www.nabble.com/The-fancy-new-entity-auto-service-execution-engine-tp18674040p21190727.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.