Closed (fixed)
Project:
Web service client
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
7 Oct 2011 at 17:10 UTC
Updated:
15 Dec 2011 at 10:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
klausiYes, sounds like a good idea. wsclient_rest.module should save those parameters in $service->settings['global parameters'] or something similar. It has to alter the web service description form to add a similar global parameter input area as for operation parameters. Then it has to check on each operation call if global parameters exist and add them accordingly. Should be pretty straight forward.
The only thing that concerns me is the additional bloat on the form, maybe we should place it in a fieldset or on a separate page.
Anyway, patches welcome.
Comment #2
webmasterkai commentedSubscribing. I'll work with nquocbao to submit a patch.
Comment #3
nquocbao commentedHi All,
Here is the first patch. I use $service->settings['global parameters'], but I think we will have to rework with entity types again. It would be better if we use $service->global_parameters instead.
I intend to include a sample service to demonstrate this feature. Any idea what kind of service I should use as example ?
Comment #4
klausitrailing white space
is a bit confusing. what about "Input for global service parameters"?
You have implemented it for all service types, so I updated the issue title.
Do we want to integrate this in Rules as well? Should the global parameters of an operation be exposed in the Rules action as well so that they could be overridden?
Should we even allow overriding of global service parameters? We could just always rely on the provided default values.
Why would it be better to use $service->global_parameters? We would have to add a DB column to the wsclient_descriptions table then.
Comment #5
nquocbao commentedYeah, i made it for all services.
I think it would be better if we allow user to override the global variables. In Google API for example, they would surely want to override the apikey parameters, wsclient only provide the interface and should not concern about parameter values.
I prefer to have the definition in global_parameters because in this way we can separate the definition with setting. I would only use setting to store value only, not definition. I actually think we should use both global_parameters and settings, in this case user can revert default value for a parameter back (only this parameter, not the whole service). If you agree, I will continue with this patch to add global_parameters
For Rules, I don't have much experience. What kind of actions or condition should we expose to rules regarding global parameters ?
Comment #6
nquocbao commentedHere is the second patch. I add global_parameters columns to the schema and add a hook_update too. Only one small concern with the way I merge the value from service edit form to service entity, don't really feel right about this. You can check in wsclient_ui.inc, line 187-197
Other than that, I think it's good to go.
Comment #7
klausiI get this error after updating: "Warning: unserialize() expects parameter 1 to be string, array given in EntityAPIController->load() (line 211 of /home/klausi/workspace/entity/includes/entity.controller.inc)." I guess you will have to insert an empty serialized array as default in the update function, for already existing services in the system.
trailing white space.
Comment #8
nquocbao commentedI just try to revert the module back to original version on my computer, create some service and enable example services, then apply the patch and run update.php. But I don't get this warning.
I'm using entity 1.0-beta-10 and the default NULL is safe for serialization right ? Can you help me double check on this issue ?
Comment #9
nquocbao commentedAlso, I'm using default Drupal distro, version 7.8
Comment #10
webmasterkai commentedI'm not seeing the warning after applying the patch and running update.php I've tried a couple of the example services. Is the warning happening on a specific page or while running a specific service? I am running the latest dev version of entity however.
Comment #11
klausiOk, I could not reproduce my error from above, so that should be ok. Trailing white spaces still need to be fixed. All comments should start capitalized and end with a "."
I tested the patch, but could not add any global parameters in the UI. You only add the form elements if global parameters already exist, why?
Then I think we do not need so many columns for global parameters, only "name" and "default value" are relevant. I think we should keep it simple and only allow primitive string global parameters for now, so remove "data type", "multiple" and "required" as they do not make sense here. Also "weight" can be left out.
why do you need this 3 lines? why can't you just save the form values as they are?
And you should add to the description text of global parameters that they will passed to every single operation in this service description.
Comment #12
nquocbao commentedOk klausi, I will roll out a patch to resolve theses.
Because the definition array and submitted array is different. You can see "default value" vs "default_value". Do you have any suggestion for that ?
Comment #13
nquocbao commentedHere is the new patch. Whitespaces are trimmed, user will be able to add new global parameters and global parameters now contains only name and default value. Hope this is fine for now.
Comment #14
klausiclass properties should use lowerCamel naming.
Files should end with the \n character.
You don't need the data types anymore, right?
When I create a new REST service I get the following PHP errors:
Notice: Undefined index: global_parameters in wsclient_service_form_submit() (line 201 of /home/klausi/workspace/wsclient/wsclient_ui/wsclient_ui.inc).
Warning: Invalid argument supplied for foreach() in wsclient_service_form_submit() (line 201 of /home/klausi/workspace/wsclient/wsclient_ui/wsclient_ui.inc).
"Specify the global parameters for the services. Global parameters will override the value of operation paramter if parameter value is empty." should be "Specify the global parameters for the service. Global parameters will be used if the value of an operation parameter with the same name is empty."
I think the operations and the data types of a service a more important, so I think the global parameters should come last in the form.
And don't forget to set the status to "neeeds review" if you provide a new patch.
Comment #15
nquocbao commentedHere is the next patch. I fix the notice error when create new service and update as you suggest. The global parameters are also moved to the bottom of the form.
For global_parameters property, I don't change it to globalParameters because it will add unnecessary code to the module to map properties from database column to object properties. I also see it's used in commerce module too. If you have any suggestion to overcome this, please advise.
Thanks.
Comment #16
klausiGreat, committed and attributed to your account: http://drupalcode.org/project/wsclient.git/commit/6c36d97
some changes:
* update 7200 changed to 7101 (make sure to change the number in the system table!)
* empty() for named parameters replaced with !isset()