Closed aksl closed 8 years ago
Also, it might be beneficial to add functions for getting firstname and lastname separately. One approach could be to extend eppInfoContactResponse with ficoraEppInfoContactResponse and add the required methods there for getting the first name and last name. ficoraEppConnection constructor can then override previous command response for Metaregistrar\EPP\eppInfoContactRequest.
Also note that some contact info responses have the contact:postalInfo > contact:name, so don't drop support for it completely on Ficora contact info responses. It is used for specifying contact person or department for a company or other organisation.
One additional thing: if you decide to extend the eppInfoContactRequest, you could add support for retrieving legalemail which is present for contact type 5 (registrant). For contact type 5, it is possible that regular email is not present, but legal email is (as seen from the xml above). Both of them can be present at the same time.
Hello Aksi,
The php-epp-client has been written in such a way that you can extend the eppInfoContactResponse to include extra fields that are created by some registries (and not by others). I would not recommend altering the default eppInfoContactResponse, because that might break your implementation if you connect to a different registry than Ficora.
Unfortunately, Ficora has not made its EPP extensions "the EPP way". Instead of implementing them as an extension object in XML, they have incorporated their changes into the main EPP structure.
But that does not matter. If you examine Protocols/EPP/eppExtensions/Ficora, you can see an example of extending the CheckBalance object.
This directory can also be used for writing additional extensions for Ficora, for example for extending the eppInfoContactResponse with extra fields.
I'll go with that way then, might do a pull request once I have something actually usable.
Handling the special fields in postal info would require extending the eppContactPostalInfo. Sadly, that would mean rewriting the entire base logic for eppInfoContactResponse->getContactPostalInfo(). Would it be possible to split the logic from getContactPostalInfo into two parts? One (getContactPostalInfoData, protected) would return an array of arrays containing the parsed elements (name, city, country, etc.) and the raw xpath query result, and then the actual getContactPostalInfo would use this for assigning them into objects. That way one could use the getContactPostalInfoData(), do additional logic on xpath query results and then use a different class if needed.
Why don't you extend the eppContactPostalInfo object with a new object (like ficoraEppContactPostalObject) and add / substitute functions where needed? I see no reason the rewrite the base logic? It is just a simple object that will convert XML into text or a PHP object structure.
That was the plan. However, I can't then use the original eppInfoContactResponse->getContactPostalInfo(), as it can't return extended objects. Guess I'll just have to rewrite that too.
And that is exactly why it is a bad thing that Ficora did not use the recommended way to extend EPP.
Merged the pull request, thanks for your contribution
In some Ficora contact info responses (where contact type is 0 (person)), the name is transmitted with separate firstname and lastname fields which are not recognized and transferred properly to eppContactPostalInfo. Example response:
Simple fix: alter eppInfoContactResponse->getContactPostalInfo() to search for firstname and lastname if name field is not present (around line 314):