New Service Execution API?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

New Service Execution API?

Scott Gray-3
Following a builder pattern a bit like EntityQuery:

ServiceResult createProductResult = ServiceContext.create(dispatcher,
userLogin)
        .add("brandName", brandName)
        .add("productName", productName)
        .add("longDescription", description)
        .add("internalName", internalName)
        .add("introductionDate", UtilDateTime.nowTimestamp())
        .add("productTypeId", "FINISHED_GOOD")
        .newTransaction()
        .runSync("createProduct");
if (createProductResult.isError()) {
    return ServiceUtil.returnError("Could not create Product: " +
createProductResult.getErrorMessage());
}
productId = createProductResult.getString("productId");


Calling a service from java always seems so cumbersome to me, maybe
something like the above would make it a little bit nicer?

Regards
Scott
Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Ashish Vijaywargiya-4
+1.

There is a limitation in UtilMisc.toMap() method where you can pass at max
6 parameters. I think here you are proposing that we will be able to pass
any number parameters to the service or there will be limitation of max 6
parameters that can be passed?

Thanks!

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997

On Thu, Jan 14, 2016 at 4:37 AM, Scott Gray <[hidden email]>
wrote:

> Following a builder pattern a bit like EntityQuery:
>
> ServiceResult createProductResult = ServiceContext.create(dispatcher,
> userLogin)
>         .add("brandName", brandName)
>         .add("productName", productName)
>         .add("longDescription", description)
>         .add("internalName", internalName)
>         .add("introductionDate", UtilDateTime.nowTimestamp())
>         .add("productTypeId", "FINISHED_GOOD")
>         .newTransaction()
>         .runSync("createProduct");
> if (createProductResult.isError()) {
>     return ServiceUtil.returnError("Could not create Product: " +
> createProductResult.getErrorMessage());
> }
> productId = createProductResult.getString("productId");
>
>
> Calling a service from java always seems so cumbersome to me, maybe
> something like the above would make it a little bit nicer?
>
> Regards
> Scott
>
Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Nicolas Malin-2
In reply to this post by Scott Gray-3
Hi Scott,

I smell good :)

Just on the order to prepare the call I think it's more readable to
start by the service name :

As like this :
ServiceResult createProductResult = ServiceWorker.init(dispatcher,
"createProduct")
       .makeValid(context)
       .add("productName", productName)
       .runSync()

Great Idea Scott, I need look into it more :)

Nicolas

  Le 14/01/2016 00:07, Scott Gray a écrit :

> Following a builder pattern a bit like EntityQuery:
>
> ServiceResult createProductResult = ServiceContext.create(dispatcher,
> userLogin)
>          .add("brandName", brandName)
>          .add("productName", productName)
>          .add("longDescription", description)
>          .add("internalName", internalName)
>          .add("introductionDate", UtilDateTime.nowTimestamp())
>          .add("productTypeId", "FINISHED_GOOD")
>          .newTransaction()
>          .runSync("createProduct");
> if (createProductResult.isError()) {
>      return ServiceUtil.returnError("Could not create Product: " +
> createProductResult.getErrorMessage());
> }
> productId = createProductResult.getString("productId");
>
>
> Calling a service from java always seems so cumbersome to me, maybe
> something like the above would make it a little bit nicer?
>
> Regards
> Scott
>

Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Scott Gray-3
We could do that but then you lose the ability to reuse the context for
subsequent calls.  Although I'm not sure it would have much use i.e.
calling different services with similar input parameters.

I created a rough version of the ServiceContext today and I must say it was
much easier to code  than working with just a Map and dispatcher.

Thanks for your input Nicolas! I'll have a think on our options.  Possibly
a .service(String) method might do the trick but I prefer to have it either
in the initial static method or in the final run method to ensure the dev
doesn't forget to specify it. Although maybe that's being too cautious.

Regards
Scott
On 14 Jan 2016 21:14, "Nicolas Malin" <[hidden email]> wrote:

> Hi Scott,
>
> I smell good :)
>
> Just on the order to prepare the call I think it's more readable to start
> by the service name :
>
> As like this :
> ServiceResult createProductResult = ServiceWorker.init(dispatcher,
> "createProduct")
>       .makeValid(context)
>       .add("productName", productName)
>       .runSync()
>
> Great Idea Scott, I need look into it more :)
>
> Nicolas
>
>  Le 14/01/2016 00:07, Scott Gray a écrit :
>
>> Following a builder pattern a bit like EntityQuery:
>>
>> ServiceResult createProductResult = ServiceContext.create(dispatcher,
>> userLogin)
>>          .add("brandName", brandName)
>>          .add("productName", productName)
>>          .add("longDescription", description)
>>          .add("internalName", internalName)
>>          .add("introductionDate", UtilDateTime.nowTimestamp())
>>          .add("productTypeId", "FINISHED_GOOD")
>>          .newTransaction()
>>          .runSync("createProduct");
>> if (createProductResult.isError()) {
>>      return ServiceUtil.returnError("Could not create Product: " +
>> createProductResult.getErrorMessage());
>> }
>> productId = createProductResult.getString("productId");
>>
>>
>> Calling a service from java always seems so cumbersome to me, maybe
>> something like the above would make it a little bit nicer?
>>
>> Regards
>> Scott
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Scott Gray-3
In reply to this post by Ashish Vijaywargiya-4
Yeah exactly Ashish, you can chain as many .add calls as you wish to add
however many parameters are needed. The method will also accept a Map for
situations where the inputs are coming from elsewhere.  We could also add
another method to take from an existing map only those parameters that the
service would accept.

Regards
Scott
On 14 Jan 2016 17:19, "Ashish Vijaywargiya" <
[hidden email]> wrote:

> +1.
>
> There is a limitation in UtilMisc.toMap() method where you can pass at max
> 6 parameters. I think here you are proposing that we will be able to pass
> any number parameters to the service or there will be limitation of max 6
> parameters that can be passed?
>
> Thanks!
>
> --
> Kind Regards
> Ashish Vijaywargiya
> HotWax Systems - est. 1997
>
> On Thu, Jan 14, 2016 at 4:37 AM, Scott Gray <[hidden email]>
> wrote:
>
> > Following a builder pattern a bit like EntityQuery:
> >
> > ServiceResult createProductResult = ServiceContext.create(dispatcher,
> > userLogin)
> >         .add("brandName", brandName)
> >         .add("productName", productName)
> >         .add("longDescription", description)
> >         .add("internalName", internalName)
> >         .add("introductionDate", UtilDateTime.nowTimestamp())
> >         .add("productTypeId", "FINISHED_GOOD")
> >         .newTransaction()
> >         .runSync("createProduct");
> > if (createProductResult.isError()) {
> >     return ServiceUtil.returnError("Could not create Product: " +
> > createProductResult.getErrorMessage());
> > }
> > productId = createProductResult.getString("productId");
> >
> >
> > Calling a service from java always seems so cumbersome to me, maybe
> > something like the above would make it a little bit nicer?
> >
> > Regards
> > Scott
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Nicolas Malin-2
In reply to this post by Scott Gray-3
Le 14/01/2016 09:56, Scott Gray a écrit :
> We could do that but then you lose the ability to reuse the context for
> subsequent calls.  Although I'm not sure it would have much use i.e.
> calling different services with similar input parameters.
Ok I understand your orientation, and I think we use call a service more
than reuse a Map for an other service, but this exists also. Maybe take
the possibility to store the service context during the call to reuse it
later on an other service
>
> I created a rough version of the ServiceContext today and I must say it was
> much easier to code  than working with just a Map and dispatcher.
>
> Thanks for your input Nicolas! I'll have a think on our options.  Possibly
> a .service(String) method might do the trick but I prefer to have it either
> in the initial static method or in the final run method to ensure the dev
> doesn't forget to specify it. Although maybe that's being too cautious.
Your initiative to simplify the service call is good, and we  have the
time to sharing about it :)
>
> Regards
> Scott
> On 14 Jan 2016 21:14, "Nicolas Malin" <[hidden email]> wrote:
>
>> Hi Scott,
>>
>> I smell good :)
I smell good effectively ^^ but I meant "This smell good"

>>
>> Just on the order to prepare the call I think it's more readable to start
>> by the service name :
>>
>> As like this :
>> ServiceResult createProductResult = ServiceWorker.init(dispatcher,
>> "createProduct")
>>        .makeValid(context)
>>        .add("productName", productName)
>>        .runSync()
>>
>> Great Idea Scott, I need look into it more :)
>>
>> Nicolas
>>
>>   Le 14/01/2016 00:07, Scott Gray a écrit :
>>
>>> Following a builder pattern a bit like EntityQuery:
>>>
>>> ServiceResult createProductResult = ServiceContext.create(dispatcher,
>>> userLogin)
>>>           .add("brandName", brandName)
>>>           .add("productName", productName)
>>>           .add("longDescription", description)
>>>           .add("internalName", internalName)
>>>           .add("introductionDate", UtilDateTime.nowTimestamp())
>>>           .add("productTypeId", "FINISHED_GOOD")
>>>           .newTransaction()
>>>           .runSync("createProduct");
>>> if (createProductResult.isError()) {
>>>       return ServiceUtil.returnError("Could not create Product: " +
>>> createProductResult.getErrorMessage());
>>> }
>>> productId = createProductResult.getString("productId");
>>>
>>>
>>> Calling a service from java always seems so cumbersome to me, maybe
>>> something like the above would make it a little bit nicer?
>>>
>>> Regards
>>> Scott
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Jacques Le Roux
Administrator
In reply to this post by Scott Gray-3
I'm all for syntactic sugar :)

Jacques

Le 14/01/2016 00:07, Scott Gray a écrit :

> Following a builder pattern a bit like EntityQuery:
>
> ServiceResult createProductResult = ServiceContext.create(dispatcher,
> userLogin)
>          .add("brandName", brandName)
>          .add("productName", productName)
>          .add("longDescription", description)
>          .add("internalName", internalName)
>          .add("introductionDate", UtilDateTime.nowTimestamp())
>          .add("productTypeId", "FINISHED_GOOD")
>          .newTransaction()
>          .runSync("createProduct");
> if (createProductResult.isError()) {
>      return ServiceUtil.returnError("Could not create Product: " +
> createProductResult.getErrorMessage());
> }
> productId = createProductResult.getString("productId");
>
>
> Calling a service from java always seems so cumbersome to me, maybe
> something like the above would make it a little bit nicer?
>
> Regards
> Scott
>
Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Ashish Vijaywargiya-4
In reply to this post by Scott Gray-3
Thanks so much Scott!! :-)

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997

On Thu, Jan 14, 2016 at 2:28 PM, Scott Gray <[hidden email]>
wrote:

> Yeah exactly Ashish, you can chain as many .add calls as you wish to add
> however many parameters are needed. The method will also accept a Map for
> situations where the inputs are coming from elsewhere.  We could also add
> another method to take from an existing map only those parameters that the
> service would accept.
>
> Regards
> Scott
> On 14 Jan 2016 17:19, "Ashish Vijaywargiya" <
> [hidden email]> wrote:
>
> > +1.
> >
> > There is a limitation in UtilMisc.toMap() method where you can pass at
> max
> > 6 parameters. I think here you are proposing that we will be able to pass
> > any number parameters to the service or there will be limitation of max 6
> > parameters that can be passed?
> >
> > Thanks!
> >
> > --
> > Kind Regards
> > Ashish Vijaywargiya
> > HotWax Systems - est. 1997
> >
> > On Thu, Jan 14, 2016 at 4:37 AM, Scott Gray <
> [hidden email]>
> > wrote:
> >
> > > Following a builder pattern a bit like EntityQuery:
> > >
> > > ServiceResult createProductResult = ServiceContext.create(dispatcher,
> > > userLogin)
> > >         .add("brandName", brandName)
> > >         .add("productName", productName)
> > >         .add("longDescription", description)
> > >         .add("internalName", internalName)
> > >         .add("introductionDate", UtilDateTime.nowTimestamp())
> > >         .add("productTypeId", "FINISHED_GOOD")
> > >         .newTransaction()
> > >         .runSync("createProduct");
> > > if (createProductResult.isError()) {
> > >     return ServiceUtil.returnError("Could not create Product: " +
> > > createProductResult.getErrorMessage());
> > > }
> > > productId = createProductResult.getString("productId");
> > >
> > >
> > > Calling a service from java always seems so cumbersome to me, maybe
> > > something like the above would make it a little bit nicer?
> > >
> > > Regards
> > > Scott
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Gil Portenseigne
In reply to this post by Jacques Le Roux
+1

It's would be a very nice improvement !

Thanks Scott.

Gil

On 14/01/2016 13:21, Jacques Le Roux wrote:
I'm all for syntactic sugar :)

Jacques

Le 14/01/2016 00:07, Scott Gray a écrit :
Following a builder pattern a bit like EntityQuery:

ServiceResult createProductResult = ServiceContext.create(dispatcher,
userLogin)
         .add("brandName", brandName)
         .add("productName", productName)
         .add("longDescription", description)
         .add("internalName", internalName)
         .add("introductionDate", UtilDateTime.nowTimestamp())
         .add("productTypeId", "FINISHED_GOOD")
         .newTransaction()
         .runSync("createProduct");
if (createProductResult.isError()) {
     return ServiceUtil.returnError("Could not create Product: " +
createProductResult.getErrorMessage());
}
productId = createProductResult.getString("productId");


Calling a service from java always seems so cumbersome to me, maybe
something like the above would make it a little bit nicer?

Regards
Scott


Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Jacques Le Roux
Administrator
We though suffered from a dozen of regression bugs when we did the Entity Query migration.
So we will need to do careful reviews when we will do the same for the New Service Execution API

Jacques

Le 15/01/2016 08:46, gil portenseigne a écrit :

> +1
>
> It's would be a very nice improvement !
>
> Thanks Scott.
>
> Gil
>
> On 14/01/2016 13:21, Jacques Le Roux wrote:
>> I'm all for syntactic sugar :)
>>
>> Jacques
>>
>> Le 14/01/2016 00:07, Scott Gray a écrit :
>>> Following a builder pattern a bit like EntityQuery:
>>>
>>> ServiceResult createProductResult = ServiceContext.create(dispatcher,
>>> userLogin)
>>>          .add("brandName", brandName)
>>>          .add("productName", productName)
>>>          .add("longDescription", description)
>>>          .add("internalName", internalName)
>>>          .add("introductionDate", UtilDateTime.nowTimestamp())
>>>          .add("productTypeId", "FINISHED_GOOD")
>>>          .newTransaction()
>>>          .runSync("createProduct");
>>> if (createProductResult.isError()) {
>>>      return ServiceUtil.returnError("Could not create Product: " +
>>> createProductResult.getErrorMessage());
>>> }
>>> productId = createProductResult.getString("productId");
>>>
>>>
>>> Calling a service from java always seems so cumbersome to me, maybe
>>> something like the above would make it a little bit nicer?
>>>
>>> Regards
>>> Scott
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: New Service Execution API?

Scott Gray-3
That's not bad considering we made many thousands of changes.
On 16 Feb 2016 04:06, "Jacques Le Roux" <[hidden email]>
wrote:

> We though suffered from a dozen of regression bugs when we did the Entity
> Query migration.
> So we will need to do careful reviews when we will do the same for the New
> Service Execution API
>
> Jacques
>
> Le 15/01/2016 08:46, gil portenseigne a écrit :
>
>> +1
>>
>> It's would be a very nice improvement !
>>
>> Thanks Scott.
>>
>> Gil
>>
>> On 14/01/2016 13:21, Jacques Le Roux wrote:
>>
>>> I'm all for syntactic sugar :)
>>>
>>> Jacques
>>>
>>> Le 14/01/2016 00:07, Scott Gray a écrit :
>>>
>>>> Following a builder pattern a bit like EntityQuery:
>>>>
>>>> ServiceResult createProductResult = ServiceContext.create(dispatcher,
>>>> userLogin)
>>>>          .add("brandName", brandName)
>>>>          .add("productName", productName)
>>>>          .add("longDescription", description)
>>>>          .add("internalName", internalName)
>>>>          .add("introductionDate", UtilDateTime.nowTimestamp())
>>>>          .add("productTypeId", "FINISHED_GOOD")
>>>>          .newTransaction()
>>>>          .runSync("createProduct");
>>>> if (createProductResult.isError()) {
>>>>      return ServiceUtil.returnError("Could not create Product: " +
>>>> createProductResult.getErrorMessage());
>>>> }
>>>> productId = createProductResult.getString("productId");
>>>>
>>>>
>>>> Calling a service from java always seems so cumbersome to me, maybe
>>>> something like the above would make it a little bit nicer?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>>
>>
>