Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow sending other valid JSON types as IIPs #10

Closed
bergie opened this issue Oct 16, 2013 · 7 comments
Closed

Allow sending other valid JSON types as IIPs #10

bergie opened this issue Oct 16, 2013 · 7 comments

Comments

@bergie
Copy link
Member

bergie commented Oct 16, 2013

Currently the FBP parser only allows strings to be defined as IIPs, but other types are also necessary.

Examples:

1 -> IN SomeNode
true -> OPEN Gate
['foo', 'bar'] -> IN OtherNode
@djdeath
Copy link

djdeath commented Oct 16, 2013

Ideally we could go as far as parsing json inputs that can then be fed to the ports of the graph.

@alfa256
Copy link

alfa256 commented Oct 18, 2013

When passing '\n' or other escaped characters they are treated as literals , this can be observed when using file writing components.
An "universal" data types proposal (instead of just using javascript types) could work accross platforms
Example:

'1' NUMBER -> IN SomeNode
'true' BOOL -> OPEN Gate
'["foo", "bar"]' STRING LIST -> IN OtherNode
'{"foo": 5, "baz": true }' OBJECT -> IN SomeThing

@djdeath
Copy link

djdeath commented Oct 18, 2013

All of the previous are JavaScript expressions, couldn't just inject them directly into NoFlo using an eval() or something?

@alfa256
Copy link

alfa256 commented Oct 19, 2013

That can lead to abuse and bugs. But yes, JSON deserializing is what has to be done, with JSON.parse or some other safe method, eval() could mess with noflo. Although i'm not really happy in retrospective with the OBJECT type for IIPs, since it could be abused into messy graph definitions, but for testing it would be really nice.
Instead of just NUMBER, we could have FLOAT, INTEGER, DOUBLE, etc. For javascript they would all be just numbers, but for other implementations it can be different. The advantage is validating the IIP string.

@djdeath
Copy link

djdeath commented Oct 19, 2013

There are easy ways to work around not using eval().
You could have something like :

el = JSON.parse("{ value: " + stringFromFbpFile + "}");

And then pass the el.value to the processes' ports.
I just find the NUMBER, LIST, OBJECT really difficult to work with.

How do you describe complex stuff like :

[true, [0, 1, 2, 3], "Plop"]
[{x: -1, y: 1}, {x: 1, y: -1}]
etc... ?

@alfa256
Copy link

alfa256 commented Oct 20, 2013

Wouldn't that be a smell? Configuring processes with contrived data structures doesn't seem smart to me at least.
It can work if you pass an object instead of a list of heterogeneous elements, otherwise it would look like noise in the FBP file, meaningless configuration string.

@tlrobinson
Copy link
Contributor

Heads up I've implemented this (basically just pulled in peg.js' JSON grammar) in #58.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants