Thanks Abdullah,
Your patch is in trunk at r816944.
Jacques
From: "Abdullah Shaikh" <abdullah.sha...@viithiisys.com>
yes :)
The only thing I started this conversation was because there were services
to get party telephone & email, but no service to get the party's
postaladdress. And I submitted the patch for the getPartyPostalAddress
service.
When there was a mention of ContactMechWorker methods
(getPartyPostalAddresses & getCurrentPostalAddress), I thought that, I will
provide another patch in place of already provide patch, wherein the
ContactMechWorker methods, will call this service instead of using the
delegator to fetch the records, to make code more generalise, but then those
methods are more specific to the requirements i.e. as per the data needed in
the groovy file.
I feel we can commit this patch as this service will be useful in various
scrips written for profile and other pages as stated by Vikas Mayur and also
to get the postaladdress remotely as can be done with email and telephone
service by making them exportable.
On Fri, Sep 18, 2009 at 7:00 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
OK, back to beginning :o)
Jacques
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
Hmm those methods do look a little bit out of the ordinary, perhaps it
might be better to just implement the service from scratch. Just be sure
to follow the same patterns as used by the other ContactMech services.
Regards
Scott
On 19/09/2009, at 12:57 AM, Abdullah Shaikh wrote:
Yes, initially I thought of that, i.e. to wrap the worker method by
service,
but both the methods expects ServletRequest object as the parameter.
Regarding moving the code to the service, there is another issue, the
getPartyPostalAddresses returns contactMech, partyContactMech &
partyContactMechPurposes objects in the result and retrieved by the
groovy
file where this method is called, same is the issue with
getCurrentPostalAddres.
I guess we can commit the patch for getPartyPostalAddress, as it just
returns the postaladdress of the specified party and the specified
contactMechPurposeTypeId which is optional. Any other thoughts ?
On Fri, Sep 18, 2009 at 6:00 PM, Scott Gray <scott.g...@hotwaxmedia.com>wrote:
I wouldn't attempt to call the service from the worker method, doing so
would require that the be signature changed which means you have to
deprecate the existing method and create a new one (which is a bit
pointless
because callers might as well call the service themselves). I would
either
use the service to wrap the worker method or otherwise move the code to
service and deprecate the worker.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 18/09/2009, at 9:23 PM, Abdullah Shaikh wrote:
cool I will do that .... it's more clear now
On Fri, Sep 18, 2009 at 2:41 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
From: "Abdullah Shaikh" <abdullah.sha...@viithiisys.com>
I got confused. You meant that you will commit the already provided
patch
?.
It was really a cursory review and I must I did not thought about
generalising.
I was having ContactMechWorker.getCurrentPostalAddress &
ContactMechWorker.getPartyPostalAddresses, in my mind, what I was
thinking
was that to make the getPartyPostalAddress service in java by taking
the
code out of the ContactMechWorker methods, and calling this service
from
the
ContactMechWorker class, or should we let ContactMechWorker methods
as
it
is
? and the getPartyPostalAddress service in simple-method as already
provided
?
Let me know.
Yes you are right, but be sure to mimic exactly current behaviours.
Thanks
Jacques
On Fri, Sep 18, 2009 at 1:06 PM, Abdullah Shaikh <
abdullah.sha...@viithiisys.com> wrote:
Hi Jacques,
I will provide the patch as discussed.
Just to be sure, what I need to do is :
1) Create a service to get party postaladdress
(getPartyPostalAddress)
2) Call this service from the
ContactMechWorker.getCurrentPostalAddress
&
ContactMechWorker.getPartyPostalAddresses
The patch that I already submitted, won't suffice, for the
ContactMechWorker methods, I guess. I will need to change it to
make it
work
as per ContactMechWorker methods, so as to get it called from these
methods.
Thanks,
Abdullah
On Fri, Sep 18, 2009 at 12:49 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi Abdullah,
I had a quick look and it seems good. I will commit I guess.
Thanks (and thank you to Sumit for the link and 1st review)
Jacques
From: "Abdullah Shaikh" <abdullah.sha...@viithiisys.com>
I feel that we should have this service,
1) To get party's data, either we should have all the code in a
class
or
all
should be exposed as a service, to avoid confusion. Right now,
it's
partially from the service (i.e. email & telephone) and partially
from
the
ContactMechWorker class. All should be exposed as a service.
2) Also, as in the case of email & telephone, we can export the
service,
no
service for postal address to export.
Does this makes sense ?, if yes, then I thought of making a
service
wrapper
for ContactMechWorker.getCurrentPostalAddress &
ContactMechWorker.getPartyPostalAddresses, but then I noticed
that
one
of
the parameter for these methods is ServletRequest object. In this
case
what
can be done is create a service and can it from the methods
above,
instead
of they hitting the delegator.
Please let me know your thoughts ? or am I missing something else
?
On Fri, Sep 18, 2009 at 2:54 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
There are ContactMechWorker.getCurrentPostalAddress
ContactMechWorker.getPartyPostalAddresses
But yes no services, maybe because it's not needed ?
Jacques
From: "Abdullah Shaikh" <abdullah.sha...@viithiisys.com>
There are services to get the party telephone & email,
getPartyTelephone &
getPartyEmail respectively, but no service to get the party
postal
address.
I can submit a patch for getPartyPostalAddress service, to get
the
party's
postal address. What do you think ?
