ModelMutator mutate argument miss match error about nem-php HOT 8 CLOSED

You have to pass an empty array to your $nemSDK->account([]) => and i will change that to be the default in the mutator, thanks. :)

Please use this package only with caution as I'm still in the development phase of it !

Basically the only things you can trust, are the ones that are also Unit Tested. Please look into the tests folder to know which classes are currently safe to use.

This will probably be a disappointment but I haven't had time to finish NIS specialization so it will need some more work first.

from nem-php.

Not really anything really planned. I am using this wrapper as a backbone to an upcoming project so I'm coding things along the way...

Definitely would make sense. Let me tell you the latest upgrades:

• implemented KeyPair creation + unit tested with nem-test-vectors
• implemented Address from public key derivation. + unit tested with nem-test-vectors
• implemented base Model Abstraction + Relationship (nothing wonderful, just a way to return objects out of NIS's returned arrays) + unit tested
• implemented base Service Abstraction + unit tested. (a so called Service holds a group of API requests specialisation)
• implemented the Account and Address Models + unit test.

so, currently I am finishing the models part which will encapsulate all returned and sent objects with NIS. What I can propose is to work on the following:

• src/Infrastructure/X implementations (with "Account" in that folder being an untested example of what it should be)
• implement unit tests for NIS API specialisations (Account::getFromPublicKey is for example a NIS API specialisation because it will let the developer handle those requests more easily. Just wanted to make the specialisation word clear.

With that we will have a ready SDK, the abstraction layer in src/Infrastructure/Service is actually already unit tested i think and can be built upon.

Services include a little PHP magic in letting you use following format of mutators:

$this->createAccountModel([..]) will create a src/Models/Account instance inside the service (a little like Eloquent model workflow)

$this->createAddressModel([]) will create a src/Models/Address instance, and so on...

$this->createBaseModel([]) is a little special in that it defines a non-specialised NIS object (it will return a src/Models/Model instance rather than any of the specialise src/Models/X classes.

I would love any contribution and feel free to ask if something is unclear! :)

from nem-php.

Thanks for the explanation @evias. I was looking into the code this evening and the mutations in the services are very well written. Kudos to your work :)

I am developing a prototype and wanted to monitor all the incoming transactions associated with an address. In the process, I was trying to create a NEM account object from a given address and I have come across a bunch of issues. It's actually returning objects with no attributes mapped.

and also here

Could you please let me know what was the best possible way to achieve this. Once I have the prototype out of the way, probably I can fork and contribute to the code base on a regular basis.

Any help would be much appreciated.

Thanks again for your time.

from nem-php.

Do you have a todo list you or the community would like to work on? Probably I can contribute a bit. Thanks for the reply anyways. :)

from nem-php.

there is a unit test checking that service returned mutated models have attributes set. Have a look, maybe its the model you use that is wrongly configured in the sdk :)

from nem-php.

oh i just found that problem on getPath(), its adding a withQuery parameter but using a buildQueryparameter :$

You might hit on several little bugs like that because I just rewrote the entire SDK part to have a correct abstraction layer for models and services. Services have not been tested well yet. And models, well, only Account and Address models have been tested up to now. (but the account models also contains so called subordinate DTOs which is the relationship feature, so Models have a good base to all be tested now).

The Transaction sub-abstraction-layer is a little more complicated, basically each TransactionType on NEM adds some data to the actual transaction data ($appends) but some transaction types also add data to a meta sub-dto, this is the extend() and extendMeta() features. Those features might still change as I'm not 100% sure they will work accordingly with NIS and I also think they might be a little overcomplicated for the task they need to fill.

Enough talk.. ping me with any bug I might know where its from and sorry for only discovering the getPath issue after a re-read :)

from nem-php.

Also, the sprintf function takes 3 parameters only 2 provided, $query missing there

I am fixing them on my local copy and adding more functionality if necessary. I shall create a pull request later so that you can then review them before merging. Thanks.

from nem-php.

Great yep I will merge :) Thank you a lot!

from nem-php.