cwyckoff-babel_icious 0.0.4.7 → 0.0.4.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/MIT-LICENSE +1 -1
- data/README.rdoc +28 -26
- data/lib/babel_icious/core_ext/libxml_node.rb +8 -1
- metadata +1 -1
data/MIT-LICENSE
CHANGED
@@ -19,4 +19,4 @@ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
|
|
19
19
|
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
|
20
20
|
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
21
21
|
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
|
22
|
-
OTHER DEALINGS IN THE SOFTWARE.
|
22
|
+
OTHER DEALINGS IN THE SOFTWARE.
|
data/README.rdoc
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
= Babel-icious
|
2
2
|
|
3
|
-
|
3
|
+
Are you tired of ugly data munging in Rails controllers or models, for instance. Well, Babel_icious is a flexible mapping tool for mapping hashes and xml. It allows you define mappings separate from your code, keeping your code clean and focused on its core responsibilities. The mappings themselves are then easy to understand and modify if and when your code changes.
|
4
4
|
|
5
5
|
|
6
6
|
== Author
|
@@ -15,7 +15,8 @@ Add a mapper for JSON.
|
|
15
15
|
|
16
16
|
== Examples
|
17
17
|
|
18
|
-
|
18
|
+
|
19
|
+
Babel_icious mappings should ideally be written in their own file or files, separate from the code that actually requires mapping. Just include the mapping files at runtime. A mapping is configured by passing mapping 'coordinates' to a 'config' block on the Mapper class:
|
19
20
|
|
20
21
|
Babelicious::Mapper.config(:foo) do |m|
|
21
22
|
|
@@ -28,7 +29,7 @@ Mappings are set up by calling passing mapping 'coordinates' to a 'config' block
|
|
28
29
|
|
29
30
|
end
|
30
31
|
|
31
|
-
The 'config' method takes a symbol as its first argument which serves as an identification tag for that mapping. The second argument is a block where you indiate the details of your mapping
|
32
|
+
The 'config' method takes a symbol as its first argument which serves as an identification tag for that mapping. The second argument is a block where you indiate the details of your mapping, which should include a direction indicator and individual mapping 'coordinates', as well as a series of 'to' and 'from' mappings. The line
|
32
33
|
|
33
34
|
m.direction :from => :xml, :to => :hash
|
34
35
|
|
@@ -47,6 +48,15 @@ the slash indicates that "bar" is a nested hash within "foo". The target xml th
|
|
47
48
|
with the value of "bar" from the hash above placed in the nested <foo> tags in the xml.
|
48
49
|
|
49
50
|
|
51
|
+
=== Translation
|
52
|
+
|
53
|
+
When you want to translate the mappings, simply call:
|
54
|
+
|
55
|
+
Babelicious::Mapper.translate(:foo, source)
|
56
|
+
|
57
|
+
passing the tag for the mapping and the actual source you want to translate from. The above line would translate the :foo mapping above.
|
58
|
+
|
59
|
+
|
50
60
|
=== Conditions
|
51
61
|
|
52
62
|
You can also qualify your mappings with the methods "unless" and "when". For example, if you do not want to translate mappings that lack a value, simply add an "unless" method:
|
@@ -62,11 +72,13 @@ if the value at "foo/bar" is empty or nil, "foo/bar" will not be translated. Ad
|
|
62
72
|
will only translate if the value at "foo/bar" begins with a capital "M".
|
63
73
|
|
64
74
|
|
65
|
-
|
75
|
+
=== Customized mappings
|
76
|
+
|
77
|
+
Babel_icious provides a few powerful ways of handling customized mappings.
|
66
78
|
|
67
|
-
|
79
|
+
==== .to
|
68
80
|
|
69
|
-
If your target mapping
|
81
|
+
If your *target* mapping depends upon one or more conditions, you may use the .to method which takes a block. The block yields the value of the source mapping for you to evaluate any conditions necessary.
|
70
82
|
|
71
83
|
m.from("foo/bar").to do |value|
|
72
84
|
if(value == "baz")
|
@@ -76,18 +88,17 @@ If your target mapping is conditional, you may use the .to method which takes a
|
|
76
88
|
end
|
77
89
|
end
|
78
90
|
|
79
|
-
Note that the .to method must be used in conjunction with .from, which takes a simple string for the source mapping.
|
91
|
+
The above mapping, for example, will use "value/is/baz" as its target mapping if the source value is "baz", otherwise, the mapping defaults to "value/is/something/else". (Note that the .to method must be used in conjunction with .from, which takes a simple string for the source mapping.)
|
80
92
|
|
81
|
-
|
82
|
-
=== .customize
|
93
|
+
==== .customize
|
83
94
|
|
84
95
|
If you have a complex mapping and need to customize it in some way, use the .customize method and pass it a block. The block yields the source object for you to manipulate. Let's say you're mapping xml to a hash where the xml source looks like:
|
85
96
|
|
86
|
-
<
|
97
|
+
<statuses><status><code>Foo</code><message>Bar</message></status></statuses>
|
87
98
|
|
88
99
|
You need to map statuses so that the output looks like [{"name" => "Foo", "text" => "Bar"}]. Here's how you could customize your mapping:
|
89
100
|
|
90
|
-
m.map(:from => "
|
101
|
+
m.map(:from => "statuses", :to => "status_code").customize do |node|
|
91
102
|
res = []
|
92
103
|
node.elements.map {|nd| res << {"name" => nd.child_content("code"), "text" => nd.child_content("message")}
|
93
104
|
res
|
@@ -95,29 +106,20 @@ You need to map statuses so that the output looks like [{"name" => "Foo", "text"
|
|
95
106
|
|
96
107
|
This mapping would produce:
|
97
108
|
|
98
|
-
{"
|
109
|
+
{"status_code" => [{"name" => "Foo", "text" => "Bar"}]}
|
99
110
|
|
100
111
|
A more common use case is concatenation of nested xml nodes. Given the following xml:
|
101
112
|
|
102
|
-
<
|
113
|
+
<institutions><institution>FOO</institution><institution>BAR</institution><institution>BAZ</institution></institutions>
|
103
114
|
|
104
|
-
You could easily concatentate institutions with the following mapping:
|
115
|
+
You could easily concatentate the institutions nested within the <institutions> node with the following mapping:
|
105
116
|
|
106
|
-
m.map(:from => "
|
117
|
+
m.map(:from => "institutions", :to => "concatenated_institutions").customize do |node|
|
107
118
|
node.concatenate_children("|")
|
108
119
|
end
|
109
120
|
|
110
|
-
|
121
|
+
This mapping would produce
|
111
122
|
|
112
|
-
{"
|
123
|
+
{"concatenated_institutions" => "FOO|BAR|BAZ"}
|
113
124
|
|
114
125
|
(note: 'concatentate' is a convenience method I've added to the libxml XML::Node object)
|
115
|
-
|
116
|
-
|
117
|
-
== Translation
|
118
|
-
|
119
|
-
Finally, when you want to translate the mappings, simply call:
|
120
|
-
|
121
|
-
Babelicious::Mapper.translate(:foo, source)
|
122
|
-
|
123
|
-
passing the tag for the mapping and the actual source you want to translate from.
|
@@ -3,7 +3,14 @@ require 'xml/libxml'
|
|
3
3
|
module BabeliciousNodeHacks
|
4
4
|
|
5
5
|
def concatenate_children(glue)
|
6
|
-
|
6
|
+
self.children.reject { }
|
7
|
+
res = self.children.inject('') do |a,b|
|
8
|
+
unless b.content.strip.empty?
|
9
|
+
a << "#{b.content.strip}#{glue.strip}"
|
10
|
+
else
|
11
|
+
a
|
12
|
+
end
|
13
|
+
end
|
7
14
|
res.chop
|
8
15
|
end
|
9
16
|
|