Feature Name Template includes container symbols

ENG_1

I would like my feature to set its name based on the type of part it's creating. It works correctly but it looks ugly because if I use setFeatureComputedParameter to assign a string to the feature name, I get the quotation marks in the name of my feature. This seems to also be the case for an array. As far as I can tell, there isn't a way to get cleanly get a string in the name, except by having the user enter a string parameter (they might as well just change the name if this is the case). Is there some work around I might be missing?

This is the concept that I would like to work:

        annotation { "Feature Type Name" : "Piping", "Feature Name Template" : "#NPS\" #PartName" }
...
        var NPS = 1
        var partName = "Pipe - " ~ pipeLength ~ "in";
...

        setFeatureComputedParameter(context, id, {

                "name" : "NPS",

                "value" : NPS

        });

        var Piping = "Piping";  

        setFeatureComputedParameter(context, id, {

                "name" : "PartName",

                "value" : partName

        });

But I get this:   

As opposed to:  println(NPS ~ "\" " ~ partName);
Which prints: 

Any ideas? I've even played around with using the names of the selected enum --  partName = definition.AddType ~ " " ~ pipeLength ~ "in";
but it still surrounds it in quotes.

kevin_o_toole_1

Everything you're saying does make sense.

The difficulty here is that for user-input strings, it is helpful to see the quotes there. (consider the variable feature, which reads e.g. #x = "foo").

The way I see to solve this problem is for us to have a special FeatureScript type named, say, TemplateFormattingString, which indicates that the string should be displayed without quotes. So your code would be written as

TemplateFormattingString;var partName = ("Pipe - " ~ pipeLength + "in") as 

(This doesn't work now! Just hypothesizing)

The downside is that it still requires the call to setFeatureComputedParameter, which doesn't scale well for array parameter names, and doesn't work for suppressed features. The upside is that it doesn't require implementing formatting logic inside the string (logic which is better written in FeatureScript), and it keeps the template string itself simple, which is important if we one day allow user editing of the template after the feature is created.

Does this seem like a reasonable solution to you?

ENG_1

Thanks for your response. Yes, I think that would be an easy solution for this type of problem, I hope to see something along its lines down the road.