woei
May 3, 2012, 12:14am
1
since the current v4p files and any subversion system are not so close friends yet, just had the idea the current xml definition into a functional and a visual part could help:
the ‘code’ part would just contain nodename, id, pinname and values, and the links.
the visual part would hold the top, left, width, height attributes, linkpoints etc…
david
May 4, 2012, 1:00am
2
and… in addition. to make patch parsing easier it would be lovely to store input pin data into childelements of each pin element (maybe “slice”)…
in terms of subversioning of v4p files… what we need is a visual diff tool for vvvv patches. indeed, the splitup would help alot already though.
Rescued this from the old wiki (anno 2006):
david:
There are several weird structures which are pretty bad to interpret with common XML Parsers. Since XML is a very flexible format for storing data it makes sense to use it, especially when we are planning to provide different interfaces for vvvv patches. These intefaces could/should be able to process the XML Tree easily. This is’t provided right now. Here are my hints:
Actual data should be stored in elements, not in attributes. There is no rule about it. But i think it is smart to differ between enumerated information (e.g.slicecount and visible) and flexible information (e.g. value of slices).
therefore the element PIN should have childelemts SLICE for every sclice. Right now we have an attribute value, which contains all values of all slices as a comma separated string. Especially for storing strings containing a comma again this is no good. you can never teach a common xml parser to split that string into the right slices.
element BOUNDS is a self closing element so it should close itself
element LINK is the same.
here is what i think:
<PATCH nodename="something.v4p">
<NODE id="2" nodename="IoBox (String)">
<BOUNDS height="" left="" top="" type="" width="" />
<LINK dstnodeid="" dstpinname="" hiddenwhenlocked="" srcnodeid="" srcpinname="" />
<PIN pinname="" slicecount="">
<SLICE>content of slice 0</SLICE>
<SLICE>content of slice 1</SLICE>
<SLICE>content of slice 2</SLICE>
</PIN>
</NODE>
</PATCH>
for conversion with old releases there would be a need of a converter. which should not be a problem because that would be just the processing of the xml as it is right now into the new format.