I want to build a SOAP client using ruby. I tried using the soap4r library to generate ruby classes out of the WSDL file, but the issue with this was that all the methods it generated were of optional kind, instead of NAME/VALUE pairs. Given that some methods have a very large number of arguments, many of which are optional, I would prefer to use something like SOAP::Lite(Perl Library) which does not depend on WSDL file and accepts arguments as NAME/VALUE pairs.
Also take a look at Savon.
I've not actually used this myself, but I remembered hearing about it the other day: Handsoap. Check it out and see if it fits your needs! ;)
Related
I am looking for a way to emit YAML files avoiding the use of aliases (mostly for simplified human readability). I think extending Psych::Visitors::Emitter or
Psych::Visitors::Visitor is the way to go, but I cannot actually find where Ruby decides whether to dump an anchor in full, or reference it with an alias.
I wouldn't even mind if the anchors were used repeatedly (with their &...... references), I just need to expand aliases to the full structures.
I am aware of similar questions being asked in the past, but:
Ruby YAML write without aliases remained unanswered
Is it possible to emit valid YAML with anchors / references disabled using Ruby or Python? gave answer for Python but not for Ruby
One simple (hacky) approach I used was convert the yaml to json. and then convert it back to YAML. new YAML does not contain aliases/anchors.
require 'json'
jsonObj = oldYaml.to_json
newYaml = YAML.load(jsonObj)
print newYaml.to_yaml
The only way I've found to do this is to perform a deep clone of the object being dumped to YAML. This is because YAML will identify the anchors and aliases based on their identity, and if you clone or dup them, the new object will be equal, but have a different identity.
There are many ways to perform a deep clone, including library support, or writing your own helper function -- I'll leave that as an exercise for the reader.
We are looking to migrate from delayed_job to resque for our site, and one of the caveats I am seeing all over is that while delayed_job used yaml for serialization, resque uses json, and because of this the hash keys and etc which are symbols need to be accessed as strings, since symbols cannot be stored in json(e.g source).
My question is, if this is true, was there a reason for picking json over yaml? Or rather is there any advantage that json offers for this situation?
There are some JSON support by using redis hashes but I never used it and I doubt it's any useful in this case.
Resque probably uses JSON instead of YAML because it's more broad. I also found a comment on this issue about that.
#defunkt
YAML does not preserve Ruby objects better - with complicated objects
it can serialize an object that it can't unserialize later. This is
unacceptable.
If you want symbol keys I believe YAJL has an option we could use to
preserve the keys. Also you could trivially call symbolize_keys on an
object if you have ActiveSupport.
https://github.com/resque/resque/issues/26
I'm attempting to (for fun and profit) add the ability to inspect objects in ruby and discover their source code. Not the generated bytecode, and not some decompiled version of the internal representation, but the actual source that was parsed to create that object.
I was up quite late learning about Rubinius, and while I don't have my head around it yet fully, I think I've made some progress.
I'm having trouble figuring out how to do this, though. My first approach was to simply add another instance attribute to the AST structures (for, say, a ClosedScope object). Then, somehow pull that attribute out again when the bytecode is interpreted at runtime.
Does this seem like a sound approach?
As Mr Samuel says, you can just use pry and do show-source foo. But perhaps you'd like to know how it works under the hood.
Ruby provides two things that are useful: firstly you can get a list of all methods on an object. Just call foo.methods. Secondly it provides a file_name and line_number attribute for each method.
To find the entire source code for an object, we scan through all the methods and group them by where they are defined. We then scan up the file back until we see class or module or a few other ways rubyists use to define methods. We then scan forward in each file until we have identified the entire class/module definition.
As dgitized points out we often end up with multiple such definitions, if people have monkey patched core objects. By default pry only shows the module definition which contains most methods; but you can request the others with show-source -a.
Have you looked into Pry? It is a Ruby interpreter/debugger that claims to be able to do just what you've asked.
have you tried set_trace_func? It's not rubinius specific, but does what you ask and isn't based on pry or some other gem.
see http://www.ruby-doc.org/core-1.9.3/Kernel.html#method-i-set_trace_func
I have one large project with components in multiple languages that each depend on some of the same enum values. What solutions have you come up with to unify enums across multiple arbitrary languages? I can think of a few, but I'm looking for the best solution.
(In my implementation, I'm using Php, Java, Javascript, and SQL.)
You can put all of the enums in a text file, then use a code generator to write out the appropriate syntax for each language from that common file so that each component has the enums. Make that text file the authoritative source of information.
You can express the text file in XML but I'd think a tab-delimited flat file would work just fine.
Make them in a format that every language can understand or has a library for. I am using JSON for this at the moment.
Then you can include it with two ways:
For development: Load it from a file/URL at runtime
good for small changes you want too see immediately
slow
For productive usage: Include it in the files
using a build script
fast
no instant feedback
I would apply the dry principle and using code generator as such you could add anew language easely even if it has not enum natively existing.
It is very common in Ruby to see methods that receive a hash of parameters instead of just passing the parameters to the method.
My question is - when do you use parameters for your method and when do you use a parameters hash?
Is it right to say that it is a good practice to use a parameter hash when the method has more than one or two parameters?
I use parameter hashes whenever they represent a set of options that semantically belong together. Any other parameters which are direct (often required) arguments to the function, I pass one by one.
You may want to use a hash when there are many optional params, or when you want to accept arbitrary params, as you can see in many rails's methods.
if you have more than 2 arguements. you should start thinking of using hash.
This is good practise clearly explained in clean code link text
One obvious use case is when you are overriding a method in a child class, you should use hash parameters for the parent method's parameters for when you call it.
On another note, and this is not only related to Ruby but to all languages:
In APIs which are in flux, it is sometimes useful to declare some or all parameters to a function as a single parameters object (in Ruby these could be hashes, in C structs, and so on), so as to maintain API stability should the set of accepted arguments change in future versions. However, the obvious downside is that readability is drastically reduced, and I would never use this "pattern" unless I'd really really have to.