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" <[email protected]> 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 >> >> >
