+1
Fixed
Weird parameter naming bug
It seems that some parameter names cause clashes with variable names. Objects can have arbitrary user defined parameters starting with an underscore. These cause problems when trying to use a var in an action which has a name containing the parameter name.
Here is a simple example:
The two variables displayed by the alert should have the same value of 'abc' but in fact they do not.
Here is a simple example:
<wire>
<actions>
<action name="init" oninit="yes">
<play action="assign" _myvar="abc" />
</action>
<action name="assign">
<sync>
<assign property="var:curr_myvar" value="_myvar" />
<assign property="var:somevar" value="_myvar" />
<play action="display" />
</sync>
</action>
<action name="display">
<alert message="'var:curr_myvar'=[var:curr_myvar] 'var:somevar'=[var:somevar]" />
</action>
</actions>
</wire>
The two variables displayed by the alert should have the same value of 'abc' but in fact they do not.
Customer support service by UserEcho
<wire>
<main>
<text name="panel1" height="100%" width="100%" onclick="assign" _myvar="abc" text="tap the screen" background="#ffffff" />
</main>
<actions>
<action name="assign">
<sync>
<assign property="var:curr_myvar" value="_myvar" />
<assign property="var:somevar" value="_myvar" />
<play action="display" />
</sync>
</action>
<action name="display">
<alert message="'var:curr_myvar'=[var:curr_myvar] 'var:somevar'=[var:somevar]" />
</action>
</actions>
</wire>
Right now they are a kind of magic variable which can cause problems like the one that I identified above when they get inadvertently substituted.
An object variable allows you to define an arbitrary attribute whose value can then be used to identify a single object. When you use an object variable you can only pass the value to an action on one level, this is different than a [var:] that can be reused in several locations once defined.
In an assign capacity, you can only use an object variable as a one to one from the object that triggers the assign to the assign. And in your case you are assigning a wire variable the value of an object variable. The difference is that a wire variable is stored on the App for the entire session, the App only remembers an object variable getting passed from the object to an action one time.
What you are suggesting above would only be useful if you were using a class to define an object tag. This could be done like this: _myvar="[param:myvar]" This creates a parameter for the object variable you want to use.
A parameter's purpose is to capture an attribute's value for reuse within the WIRE. This allows the same class or object to be used many times with different content.
The problem here is that a programmer defined attribute on a <panel> type object is being referenced in an action triggered by that panel object NO special notation is used to indicate that the programmer is attempting to use that attribute (for example by wrapping it with [param:someobjectattribute]), so it is ambiguous and there is an opportunity for the wire to break.
For example:
<panel name="somename" ... _value="abc" onclick="dosomething" />
...
<alert name="dosomething">
<alert message="value of curr_value is 5">
</alert>
did I mean to print exactly what is in the above quotation marks or did I really want "_value" to be substituted with the programmer defined attribute _value from the <panel> object that I clicked on to get the action.
Without wrapping the attribute name with some special notation, as is used with the other variable types, the program is unable to determine my intentions leading to exactly the kind of difficult to track down problem I experienced.
Now that the WIRE is a little older we have more advanced concepts of variables and parameters you can use, yet our legacy code is still available for use. In other words there is more than one way to skin a cat.
I understand what you are saying in your example, however it seems that if you plan to use object variables in your object that you would need to be more aware of the usage in the action it calls. Since it functions only at one level and serves to replace a value anyway, we feel that is a manageable request.