Transformations are not supported

[boc-tothefuture]

No description provided.

[jimtng]

Transformations are available via Actions, e.g.

Transformation.transform('JSONPATH', '$.test', '{ "test": "foo" }')

How do we make this more "Ruby-friendly" to the library users?

Option 1: straight forward basic syntax

test = transform :JSONPATH, '$.test', source_string

Option 2: should we create a specific method for each transformation service, e.g.

transform_json '$.test', source_string
transform_map 'map_file.map', source
transform_javascript 'scriptname.js', source
transform_exec ....

#or should it be named
json_transform 
map_transform
javascript_transform
...

The availability of each transformation service depends on what's installed. We'd need to find a way to get the list of available transformation services to create the corresponding methods.

I am beginning to worry about encroaching into user's namespace, since we already have say, play, notify etc (from Actions).

[pacive]

IMHO it's okay to have some methods available, such as say, notify etc, like in the DSL rules, but I agree we shouldn't pollute the namespace too much. But to have a generic transform method where you can pass the transformation service as an argument (string or symbol) would be a good idea.

Generally I think that to make it as simple as possible for users, things should be as similar to the DSL as possible, but with the added functionality and simplicity that ruby entails.

[jimtng]

Generally I think that to make it as simple as possible for users, things should be as similar to the DSL as possible

I agree that transform should be made available as it is on RulesDSL.

We can make the service name case insensitive and also support string and symbol, so it could be :jsonpath, :javascript, :map, etc.

[boc-tothefuture]

I haven't looked into this to determine what is possible. I agree we should handle the case close to the dsl with a three argument method. It would be good in that case to support symbols and strings for the transform type.

Additionally it may be beneficial to support each transform type as a method on a transform object.

transform.map(file, value)
transform.js(file, value)

I also wonder if transforms should be additionally associated with item states, which I think is a very common use case.

Item.transform(:map, file)
Item.map(file)
Item.js(file)