(Migrated) SIO Hierarchy

(This message has been automatically imported from the retired mailing list)

Hi,

I have a questions about SIO usage, which can become a feature
suggestion if the response is negative:
Is there any way to use nested documents in the
required_input/required_output specification?

So, to use a simple example:

I have the following Json:
{
“name”: {
“first”:“Test”,
“second”:“User”
}
}

And want to respond:
{
“id”:123,
“status”: {
“account”:“Active”,
“email”:“Validated”
}
}

How would I specify “first” and “last” as required_input, and "account"
and “email” as required_output?
And most importantly, how would I access them?

If this is not implemented (I think it’s not), a possibility would be to
indicate the nested documents with a “.” hierarchy:

required_input = (“name.first”,“name.second”)
required_output = (“id”,“status.account”,“status.email”)

And access them the same way:
self.request.input.name.first
self.response.status.account

Regards,
Carles

On 04/25/2014 05:51 PM, Coeuz wrote:

How would I specify “first” and “last” as required_input, and "account"
and “email” as required_output?
And most importantly, how would I access them?

If this is not implemented (I think it’s not), a possibility would be to
indicate the nested documents with a “.” hierarchy:

required_input = (“name.first”,“name.second”)
required_output = (“id”,“status.account”,“status.email”)

Hello Coeuz,

you are right that it’s not possible right now although the newest
structures in GH master allow you to express similar intent. I’m
thinking of List, Dict and ListOfDicts SIO types - here you can see them
in action:

https://github.com/zatosource/zato/blob/master/code/zato-server/test/zato/server/live/zato_test_live_sio.py

This is close but no biscuit - they’re not exactly what you’re looking
for and I like your idea of dot-separated elements.

Question is, how to express data types and the optional nature of
certain elements?

No matter how much I like the Hungarian language I just can’t think
warmly of the Hungarian notation but still I guess we would have to
employ something like:

(‘name.first’, ‘name.i_account_no’, ‘name.address.b_for_priv’)

Now, supposing ‘address’ were optional but once it was provided,
‘for_priv’ were not, we would have something akin to:

(‘name.first’, ‘name.i_account_no’, ‘name.?address.b_for_priv’)

Now, we could do away with a lot of those if we expanded the default
prefix and suffix mappings to data types.

For instance, right now - is_* and should_* indicate a boolean value.

There is nothing preventing us from adding more of these, like

  • *_no
  • *_number
  • *_num

(and similar) would all indicate integers.

I’m a big fan of useful conventions over detailed configuration and I
trust people would prefer to use such particular name patterns instead
of the Hungarian notation - which would still be there, just in case
it’s needed.

We’d really need to think about how it would work for bigger documents -
say, a schema of 100 input elements, various data types - lists, dicts,
ints, floats, booleans - half of these optional.

Perhaps we’d need to find a well-defined schema and try to express it
using the syntax as above, or a similar one that we’d work out here.

What do you think about it?

On 04/25/2014 05:51 PM, Coeuz wrote:

How would I specify “first” and “last” as required_input, and "account"
and “email” as required_output?
And most importantly, how would I access them?

If this is not implemented (I think it’s not), a possibility would be to
indicate the nested documents with a “.” hierarchy:

required_input = (“name.first”,“name.second”)
required_output = (“id”,“status.account”,“status.email”)

Hello Coeuz,

you are right that it’s not possible right now although the newest
structures in GH master allow you to express similar intent. I’m
thinking of List, Dict and ListOfDicts SIO types - here you can see them
in action:

https://github.com/zatosource/zato/blob/master/code/zato-server/test/zato/server/live/zato_test_live_sio.py

This is close but no biscuit - they’re not exactly what you’re looking
for and I like your idea of dot-separated elements.

Question is, how to express data types and the optional nature of
certain elements?

No matter how much I like the Hungarian language I just can’t think
warmly of the Hungarian notation but still I guess we would have to
employ something like:

(‘name.first’, ‘name.i_account_no’, ‘name.address.b_for_priv’)

Now, supposing ‘address’ were optional but once it was provided,
‘for_priv’ were not, we would have something akin to:

(‘name.first’, ‘name.i_account_no’, ‘name.?address.b_for_priv’)

Now, we could do away with a lot of those if we expanded the default
prefix and suffix mappings to data types.

For instance, right now - is_* and should_* indicate a boolean value.

There is nothing preventing us from adding more of these, like

  • *_no
  • *_number
  • *_num

(and similar) would all indicate integers.

I’m a big fan of useful conventions over detailed configuration and I
trust people would prefer to use such particular name patterns instead
of the Hungarian notation - which would still be there, just in case
it’s needed.

We’d really need to think about how it would work for bigger documents -
say, a schema of 100 input elements, various data types - lists, dicts,
ints, floats, booleans - half of these optional.

Perhaps we’d need to find a well-defined schema and try to express it
using the syntax as above, or a similar one that we’d work out here.

What do you think about it?