CallMethod; CallMethodAdvanced
Posted: May 13th, 2022, 10:40 am
While working on E-Commerce 5.1 Base, I noticed all the callmethods are CallMethodAdvanced. I discussed with the internal team and this should be used for 2 reasons:
1. CallMethodAdvanced has a Classic flag which when set to True will change how the output was read. This was added so applications upgraded to EP 5.1 MVC from EP 5.1 Classic or below will not require any changes (backwards compatibility). The base 5.1 EASYCommerce I'm working on is an example of this, so it makes sense that all the call methods are CallMethodAdvanced to make use of this.
2. If a developer has a complex use and based on an XSL Choose or If, a different method should be called (that cant be accomplished with a binary decision directing to 2 different CallMethod services).
The CallMethod has the advantage of having defined parameters in the middle blue panel which the CallMethodAdvanced will not have. This makes it easier to not make mistakes in what the method accepts (it's possible to make typos in CallMethodAdvanced).
So that all is clear. While comparing the two I came across a visual bug/shortcoming that I would like to report that currently exists in both services.
I started with 5 separate parameters defined in the child process input.
At this point, the Parameters in the CallMethod/CallMethodAdvance will update to the newly defined inputs.
However when I delete all but one input parameter. These are the results:
The parameters tab will reset. The parameters XML tab reverts back to the original save.
Here is another screenshot where I Assigned 5 parameter values and deleted NewParameter3, NewParameters4, and NewParameter5 from the child method assistant.
Note: No data is lost, but when I reopen the service, if I do not select the XML mode, the blue middle panel only has nodes for the currently defined input for the method. This means I can't edit the nodes that no longer exist.
SUGGESTION: I think it should still show all the inputs it used to have in the blue middle area, but the boxes for the inputs that have been removed should be red to show they are no longer there. This allows the user to edit and remove the data to "fix" the callmethod and it draws attention to something being wrong with it
1. CallMethodAdvanced has a Classic flag which when set to True will change how the output was read. This was added so applications upgraded to EP 5.1 MVC from EP 5.1 Classic or below will not require any changes (backwards compatibility). The base 5.1 EASYCommerce I'm working on is an example of this, so it makes sense that all the call methods are CallMethodAdvanced to make use of this.
2. If a developer has a complex use and based on an XSL Choose or If, a different method should be called (that cant be accomplished with a binary decision directing to 2 different CallMethod services).
The CallMethod has the advantage of having defined parameters in the middle blue panel which the CallMethodAdvanced will not have. This makes it easier to not make mistakes in what the method accepts (it's possible to make typos in CallMethodAdvanced).
So that all is clear. While comparing the two I came across a visual bug/shortcoming that I would like to report that currently exists in both services.
I started with 5 separate parameters defined in the child process input.
- Method2.PNG (12.17 KiB) Viewed 1025 times
- Method2.PNG (12.17 KiB) Viewed 1025 times
Here is another screenshot where I Assigned 5 parameter values and deleted NewParameter3, NewParameters4, and NewParameter5 from the child method assistant.
SUGGESTION: I think it should still show all the inputs it used to have in the blue middle area, but the boxes for the inputs that have been removed should be red to show they are no longer there. This allows the user to edit and remove the data to "fix" the callmethod and it draws attention to something being wrong with it