Thanks to Pawan Verma for reporting, everyone for the discussion and Scott for
the detailed argumentation which makes totally sense,
I created https://issues.apache.org/jira/browse/OFBIZ-9708 for that, and will
create the definitions
Jacques
Le 11/09/2017 à 23:32, Scott Gray a écrit :
I'm in favor of keeping them and adding the service definitions. As Taher
mentions, these are CRUD services and IMO if we have the table, we should
have the set of services allowing management of the data.
These implementations are quite synonymous with the FacilityContactMech
services, they're only gathering dust because we don't have very advanced
work effort management screens and in cases where we do, the work effort is
usually bound to a facility where the work will take place so the contact
mechs from the facility are used.
The moment somebody wants to start doing some event management with OFBiz,
these services would become useful. What we have here is a gap in the work
effort management screens, not a code bloat problem.
Regards
Scott
On 11 September 2017 at 00:15, Jacques Le Roux <jacques.le.r...@les7arts.com
wrote:
Here, it's not about Minilang but only service definitions
Jacques
Le 10/09/2017 à 13:23, Michael Brohl a écrit :
I think if we have code which is not used or planned to be used, it
should be removed.
Since we agreed on deprecating minilang, no code is allowed to be
commited using minilang with the exception of a bug fix. We shoul be very
restrictive in this case.
I agree that we should first provide a test or convert a mini lang test
and provide it along with the converted code. This will be an imporvement
on the test coverage and also prove that the converted code works the same
as the minilang version.
Thanks,
Michael
Am 01.09.17 um 11:34 schrieb Jacques Le Roux:
There will be years before we rewrite all the Minilang services. It's
just an hour to revive these services, I can do it
It will then be easy to rewrite them with all the others.
BTW I fear this moment of massive regressions if we don't put ALL the
required tests before doing the rewriting.
Jacques
Le 01/09/2017 à 11:23, Taher Alkhateeb a écrit :
Well .. according to you, the thoughts were put in these services before
the apache era! I'm not sure if we want such _very_ old code revived. I
also think the community is capable enough of rewriting basic CRUD
services. There is no magic or incredibly sophisticated algorithms in
this
code. Juat another CRUD.
On Sep 1, 2017 12:16 PM, "Jacques Le Roux" <
jacques.le.r...@les7arts.com>
wrote:
I disagree, some thoughts were put in these services. They are in
Minilang
admittedly, but we can still keep them and transform them later and
anway
we have tons of Minilang services.
I'm not sure if I found them all but they seem to start from
updateWorkEffortContactMech and end at updateWorkEffortEmailAddress.
They
all use updateWorkEffortContactMech which is only used by them and has
also
no definition.
It's 168 lines of Minilang
Jacques
Le 01/09/2017 à 10:47, Taher Alkhateeb a écrit :
I agree, we need to remove from the pile not add to it. Deleting is the
best course of action IMHO. Heck even some of the defined services
should
be deleted or heavily refactored for that matter.
On Sep 1, 2017 11:33 AM, "Pierre Smits" <pierre.sm...@gmail.com>
wrote:
If the services are not used, we should ask ourselves whether it would
not
be best to remove these to keep the code base clean. If need be these
can
always be brought back from the repo.
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OEM: the unaffiliated OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Thu, Aug 31, 2017 at 9:52 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi Pawan,
These services implementations were created before the Apache era.
I suggest we simply create the corresponding definitions and test
they are
OK
Jacques
Le 31/08/2017 à 19:38, Pawan Verma a écrit :
Hello Devs,
I just walked through from *WorkEffortSimpleServices.xml* and noticed
that
some of the simple methods neither have any service definition nor
used
anywhere. Some of the examples are createWorkEffortPostalAddress,
createWorkEffortTelecomNumber
etc. I was expecting that it must be there.
So I was just curious to know why it was not there, was it
intentional?
Or
it will be done under the Minilang deprecation task going on? Please
let
me
know if anyone has any information on it else I would be more than
happy
to
provide a patch to get it fixed now.
--
Thanks and Regards,
*Pawan Verma* | Sr. Enterprise Software Engineer
HotWax Commerce <http://www.hotwax.co/> by HotWax Systems
<http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part ||, Near Brilliant Convention Center,
Indore,
M.P, India - 452010
Cell phone: +91 9977705687
