-
Notifications
You must be signed in to change notification settings - Fork 668
comments are not serialized with custom node input nodes #8825
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
Conversation
needs tests
|
@mjkkirschner Does |
|
@ramramps |
| using Dynamo.Engine; | ||
| using Dynamo.Scheduler; | ||
| using Newtonsoft.Json.Linq; | ||
| using Dynamo.Library; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added this for Nodes.CustomNodes.Symbol type check?
|
@mjkkirschner is there a reason for not adding this to |
| //if the nodeView's model is a symbol node add some extra data. | ||
| if ((value as NodeViewModel).NodeModel is Symbol) | ||
| { | ||
| jobject.Add("Summary", ((value as NodeViewModel).NodeModel as Symbol).Parameter.Summary); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you check if empty summary will be kept and serialized as empty string? Just curious
|
I asked the same thing, should we add another field to Parameter? I'm fine with that. |
|
It's better than adding it to the TypeName field as a comment, which is what this looks like it is doing. If we add Parameter.Description it matches Port.Description. I guess the alternative would be adding it under View.NodeModel. |
|
@gregmarr this PR is meant to go into a release quite soon, not just master. Does that cause any issues if we move this to parameter? Summary already exists on paramter so it's very simple AFAIK to just serialize summary into the parameter... I'm not sure what you mean here |
|
I'm talking about adding it to the JSON Schema. |
|
right, so we would get: @ramramps @QilongTang are we okay with that? |
|
@gregmarr would this change to the schema make it into production? |
|
Can we use |
|
@mjkkirschner I am fine with it given that it is much cleaner, I just thought we do not want to implement it that way in the first place because this looks like a schema change |
|
We're generally okay with additions to the schema. Since it's adding data that isn't otherwise there, it won't hurt anything. We can have this in CoGS dev immediately, staging and production fairly soon. |
|
Well, I'm the one who didn't include it in the schema in the first place, so I'm fine with it. :) |
|
@ramramps @gregmarr @QilongTang I will change this implementation to serialize like this: |
|
"Description" = "Summary" ? |
|
yes @gregmarr requested that above to match port. |
|
Thanks @mjkkirschner just read the comments.. I am fine with Description... |
|
@QilongTang @ramramps made the changes PTAL. |
|
Any other tests you can think of that I should add here? |
| writer.WritePropertyName("DefaultValue"); | ||
| writer.WriteValue(((TypedParameter)value).DefaultValueString); | ||
| writer.WritePropertyName("Description"); | ||
| writer.WriteValue(((TypedParameter)value).Summary); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
|
This looks better [ graph serialization / deserilization] . thanks @mjkkirschner |
* first commit - seems to be working needs tests * get rid of nodeViewModel converter * add tests fix comment
* swtich registration of js object to async verison - we only have access to methods here, and they return promises. * review comments * Update library.html review comments * comments are not serialized with custom node input nodes (#8825) * first commit - seems to be working needs tests * get rid of nodeViewModel converter * add tests fix comment
Purpose
@andydandy74 reported missing comments in his converted clockwork package.
This PR serializes type parameter comments into the nodeView of input(symbol) nodes, using as simple as a converter as I could write.we use the new converter when saving the workspaceViewModel.At load time, we pull the comment out of the nodeView if the node we're loading is an input node, and then we construct a new type parameter using that comment and existing type paramter, and then set the inputSymbol equal to the string representation of that new type parameter.This PR serializes the
typedParameter.Summaryas Description using the existingTypedParamterConverterand adds some tests. It appears that if we load an existing custom node with no Description in the parameter we get an emptyString back from the symbol node - seems reasonable to me.comments are always appended to the start of the input symbol and they are always wrapped with block comments as the parser throws away everything but the comment's string value. - ie
for
//a commentwe can only serializea commentsample serialization:
TODO:
Declarations
Check these if you believe they are true
*.resxfilesReviewers
@QilongTang
@ramramps
FYIs
@smangarole @andydandy74