Multileveled structures

On our radar
I would really like to see multi-dimensional structures in the future, right now its pretty complex to build xml based on the current implementation of structures, and local variables are not an option because when the xml changes you have to change them everywhere in your application (because they are copy-pasted over)

When you have a medium sized xml and have a structure that uses other structures to represent it, the number of structures quickly grows, resulting in over a hundred easily for an app that uses only 10 medium sized xml's.
A way of grouping them (other then prefixing the name) is needed, or a way to make one single structure multileveled (why not? the underlying xml in the outsystems platform itself supports it right?)

With the multileveled structures also comes the need for a good mapper like we see in ESB products like Tibco, MuleStudio etc. (instead of just the assign which takes much time/work to make complex mappings with)
Like this:

Or this:

It would make working with XML, and exchanging information with other XML/Soap based applications much easier, and Outsystems as a platform more mature.
Created on 21 May 2015
Comments (5)
MUST HAVE! Also for Rest/Json datasets
I am not sure what the idea exactly is.

You can have multilevel structures already?

If you mean a an improvement how assigns will work, then yes
(but autoassign pretty much does the job for 80%)

Statler i thought i explained it quite detailed, did you read all of it?
I said in order to make them multileveled you end up with hundreds of structures (because you have to reference another structure in your structure) all at the same level in the tree (making it very unorganized)

What im advocating here is to have level depth inside one structure object (and preferable blueprint it from an existing xsd) instead of the need to create all those seperate structures.
Yes I read all of it. It was detailed, but unsure what the biggest issue/idea was.

what I read:

1. it's complex to build structures? what's complex about it? it's not fun, but complex??

2. local variables are not an option, because they are copied-paste?  err, what? if a structure changes, you have the power of truechange. what am I missing?

3.organizing,  you can organize structures in different espaces. 
for example,  Import a dummy wsdl and you have a blueprint for all your structures....
imho, most issues lies in the fact the xml is a pokemon, we want all structures in one go, everything is optional.

4. mapping. like 1, it's not fun, but doable.
and you can make wrappers around it to make life easier for you in business logic.
which you should do anyways, since it's an interface.

so in short, I agree with the idea to have a better assign-implementation for nested-structures :)

Your point 3 is exactly what im advocating, i want all structures of an xml in one go, and also by the way the ability to generate it from an xsd not just from a wsdl (i know an xsd is easy convertable to a wsdl, but it feels stupid i have to do it manual, very un-outsystems-like)

I know everything is possible right now, just taking me way longer then i would like, often i wonder if it would have been faster using code.

Graphical mappers are a thing right now in many platforms and add to the quality of life for programmers.