It seems that CodeEffect library 4.3.2.6 has an issue with rule XML editing ON UI and transformation back from stroage to show it on UI for editing when rule XML has In Rule method call with string parameter that has string value passed in longer than 255 characters.
Is it made intentionally to avoid long rules to be edited on UI or just a bug so someone knows workaround for it?
To avoid any side effects from my code I downloaded and used Business Rule code example from codeeffects site Code Effects Demo Projects and opened it in VS2015.
In "Patient.cs" file added following code to
public class Patient
{
...
// In Rule Method that accepts only one string parameter
[Method("[NumberOfSegments]")]
public int RuleMethod01(
// explicitly specify maximum string allowed
[Parameter(ValueInputType.User,Max = 10000)]
string val)
{
return val.Split(',').Length;
}
}
On UI(using Ajax controller) I attempted to create rule with long string parameter passed in (in real project I need such long string since it contains unique parameters for In Rule method to use for calculations and cannot rely on the data sources approach that CodeEffects can offer)
Check if [NumberOfSegments] ("1111,2222,33333,4444,55555,6666,777,8888,999,0000,1111,222,333,44444,1231231,123123123,123123123,123123123,123123123,123123123,123123123,123123123,123123123,123132123,123123123,123123123,123123123,123123123,12123123,123123123,123123123,123123123,1231231233") greater than 12
But even that I explicitly specified maximum string length for parameter as 10000 in attribute Parameter UI does not allow me to enter string that has length more than 256 characters.
Documentation on CodeEffects site
Business-Rules-Data-Types does not mentioned any built-in restrictions and only way to restrict length of the string parameter use Parameter Attribute and its Max property.
Did anyone ran into the issue with such "synthetic" restrictions and can point me to the documentation or any workaround for that?
Thank you in advance for the any meaningful suggestions
PS: Just small update - when I manually edited Rule XML file and provided longer string as parameter (e.g. around 500 characters) I could not load it from the XML back to the UI the RuleEditor::Rule::InvalidElements collection contained one element with Hint property value "v122" dont know if its helpful but may be CodeEffects authors can know more about such Hint and what v122 means.
Strings longer than 255 chars (neither property values nor method params) are not supported in Code Effects. v122 is the error number that you get in response. Its original message is "The length of the value of this string element exceeds the maximum allowed limit".
Related
I'm trying to call a method as follows:
<cfinvoke component="#variables.target#"
method="#arguments.methodName#"
argumentcollection="#arguments.args#"
returnvariable="rtn">
</cfinvoke>
However, I am getting the following error:
Unable to invoke CFC - The data for 'param_value' must be no more than
100 characters in length.' faultDetail:''
The variable arguments.args is a struct and one of its elements looks like this:
{
param_name: 'property_uid',
param_value : '00000000-0000-0000-0000-0000000213131200,00002131300-0000-0000-0000-000000000000,00000000-0000-0000-0000-0000000002122,00000000-0000-0000-0000-000000032242
}
I know the problem is caused by this element, but don't know how to fix it.
Note that I've already updated the Maximum number of POST request parameters from 100 to 300 in the CF Administrator.
The variable property_uid is currently a list and the list's value is too long to be passed in as a struct key's value. Use listToArray() to send the data as an array. Inside the function, convert it back using arrayToList() if you need the data as a list again.
Please check the code of the invoked function (the function name can be found in your variable arguments.methodName in the component of variables.target).
Look for the tag <cfparam name="param_value" ...> and check if there is a maxlength attribute defined. It's probably set to 100 and thus causes ColdFusion to throw an exception if you pass more than 100 characters to said parameter.
Having a limit of 100 characters is probably a design descision on your side (database scheme?), so you need to figure this out by yourself.
I need to set the Xaml property of a RichTextBox user control via a binding expression in Windows Phone 8, and I found that it is not a DP, so I have decided to inherit from a RichTextBox and add a DP that will change the Xaml property with PropertyChanged event, anyways the code looks like this, stripped out irrelevant parts.
public class RichTextBoxWithBindableXaml : RichTextBox
{
public string BindableXaml
{
get { return (string)GetValue(BindableXamlProperty); }
set { SetValue(BindableXamlProperty, value); }
}
public static readonly DependencyProperty BindableXamlProperty =
DependencyProperty.Register("BindableXaml",
typeof(string),
typeof(RichTextBoxWithBindableXaml),
new PropertyMetadata(0));
}
//xaml code
<local:RichTextBoxWithBindableXaml BindableXaml="{Binding PageContent , Mode=OneWay}"> </local:RichTextBoxWithBindableXaml>
And I get the following dreaded exception message:
Object of type 'System.Windows.Data.Binding' cannot be converted to type 'System.String'.
I have checked many solutions to these exceptions and similar problems with data binding, and still going through the suggested similar questions on the right, and still cannot see why a simple thing wont work for me. The code I listed above is just the simplest implementations of a DP with a binding expression. Btw, the source PageContent is from a INotifyPropertyChanged object, and it works, I know because, it can bind to TextBlock's Text property.
Am I missing out something so obvious? I wouldn't want to post question for such a straightforward thing, but I cant seem to solve in any way.
EDIT:
Following P.S note turned out to be completely irrelevant.
P.S. My final doubt was on the way xmlns namespace local is loaded. It is loaded as clr assembly, could xaml parser think my custom inherited class as clr-only and confuse since clr properties are not dependency properties. Hope it doesnt sound stupid, i'm desperate. It is as such :
xmlns:local="clr-namespace:RumCli"
I found out that I should either provide a null PropertyMetadata (new PropertyMetadata(null) instead of 0), or a metadata with a default value type if the DP is supposed to be used in Xaml. For my sceneario, since I will make use of the PropertyChangedCallback, the propertymetadata that will passed to the Register method looks like this.
new PropertyMetadata(default(string), new PropertyChangedCallback(OnBindableXamlChanged))
hope, it helps to others.
For each dependency property one must supply a non subscribed value (not a C# term here) which suites the type of object which the consumer will access.
To quote MSDN Dependency Property Metadata
Dependency property metadata exists as an object that can be queried to examine the characteristics of a dependency property.
So for the value type results, a default for the different value types, such as a double is to use double.NaN. A decimal use decimal.Zero. While a string, string.empty is good as a base.
That allows whatever operation which may blindly reflect off of the property, it can determine what its true property type is and access it accordingly.
So assigning 0 to a string makes no sense in identifying that the property is a string which 0 identifies it as an integer. So the int as string is setting up a future runtime failures when objects try to assign bindings, styles and other items to it.
I'm working on a project that's integrating with StrobeMediaPlayback and have been having trouble working out why I can't get my media loaded.
One of the two available public functions for the class is:
public function loadMedia(..._):void
If this is a rest parameter, there's no use of '_' as an argument list within the function.
What's going on here? The class extends Sprite, so its not a case of an override.
It is the ... (rest) parameter.
The parameter does not need to be called rest; it can have any name that is not a keyword.
Valid variable names start with a non number character and can include alphanumeric characters, the underscore and the dollar sign. So _ is a valid name for a parameter.
The question why exactly the parameter was named that way can probably only be answered by the author of that function. So here's what I think: Aside from its use as a short variable name for often used objects (like $ as shorter name for jQuery in javascript), the name _ is sometimes used as a placeholder, or unused variable. If I understand the question right, an the variable isn't even used in the function, it probably was added for future use. This way the API wouldn't need to be changed once the feature based on this parameter will be implemented. The developers maybe thought that a parameter name with semantic meaning could confuse the users, as they would expect it to actually doing something.
Imagine an instance of some lookup of configuration settings called "configuration", used like this:
if(! string.IsNullOrEmpty(configuration["MySetting"])
{
DoSomethingWithTheValue(configuration["MySetting"]);
}
The meaning of the setting is overloaded. It means both "turn this feature on or off" and "here is a specific value to do something with". These can be decomposed into two settings:
if(configuration["UseMySetting"])
{
DoSomethingWithTheValue(configuration["MySetting"]);
}
The second approach seems to make configuration more complicated, but slightly easier to parse, and it separate out the two sorts of behaviour. The first seems much simpler at first but it's not clear what we choose as the default "turn this off" setting. "" might actually a valid value for MySetting.
Is there a general best practice rule for this?
I find the question to be slightly confusing, because it talks about (1) parsing, and (2) using configuration settings, but the code samples are for only the latter. That confusion means that my answer might be irrelevant to what you intended to ask. Anyway...
I suggest an approach that is illustrated by the following pseudo-code API (comments follow afterwards):
class Configuration
{
void parse(String fileName);
boolean exists(String name);
String lookupString(String name);
String lookupString(String name, String defaultValue);
int lookupInt(String name);
int lookupInt(String name, int defaultValue);
float lookupFloat(String name);
float lookupFloat(String name, float defaultValue);
boolean lookupBoolean(String name);
boolean lookupBoolean(String name, boolean defaultValue);
... // more pairs of lookup<Type>() operations for other types
}
The parse() operation parses a configuration file and stores the parsed data in a convenient format, for example, in a map or hash-table. (If you want, parse() can delegate the parsing to a third-party library, for example, a parser for XML, Java Properties, JSON, .ini files or whatever.)
After parsing is complete, your application can invoke the other operations to retrieve/use the configuration settings.
A lookup<Type>() operation retrieves the value of the specified name and parses it into the specified type (and throws an exception if the parsing fails). There are two overloadings for each lookup<Type>() operation. The version with one parameter throws an exception if the specified variable does not exist. The version with an extra parameter (denoting a default value) returns that default value if the specified variable does not exist.
The exists() operation can be used to test whether a specified name exists in the configuration file.
The above pseudo-code API offers two benefits. First, it provides type-safe access to configuration data (which wasn't a stated requirement in your question, but I think it is important anyway). Second, it enables you to distinguish between "variable is not defined in configuration" and "variable is defined but its value happens to be an empty string".
If you have already committed yourself to a particular configuration syntax, then just implement the above Configuration class as a thin wrapper around a parser for the existing configuration syntax. If you haven't already chosen a configuration syntax and if your project is in C++ or Java, then you might want to look at my Config4* library, which provides a ready-to-use implementation of the above pseudo-code class (with a few extra bells and whistles).
Do you often see in API documentation (as in 'javadoc of public functions' for example) the description of "value limits" as well as the classic documentation ?
Note: I am not talking about comments within the code
By "value limits", I mean:
does a parameter can support a null value (or an empty String, or...) ?
does a 'return value' can be null or is guaranteed to never be null (or can be "empty", or...) ?
Sample:
What I often see (without having access to source code) is:
/**
* Get all readers name for this current Report. <br />
* <b>Warning</b>The Report must have been published first.
* #param aReaderNameRegexp filter in order to return only reader matching the regexp
* #return array of reader names
*/
String[] getReaderNames(final String aReaderNameRegexp);
What I like to see would be:
/**
* Get all readers name for this current Report. <br />
* <b>Warning</b>The Report must have been published first.
* #param aReaderNameRegexp filter in order to return only reader matching the regexp
* (can be null or empty)
* #return array of reader names
* (null if Report has not yet been published,
* empty array if no reader match criteria,
* reader names array matching regexp, or all readers if regexp is null or empty)
*/
String[] getReaderNames(final String aReaderNameRegexp);
My point is:
When I use a library with a getReaderNames() function in it, I often do not even need to read the API documentation to guess what it does. But I need to be sure how to use it.
My only concern when I want to use this function is: what should I expect in term of parameters and return values ? That is all I need to know to safely setup my parameters and safely test the return value, yet I almost never see that kind of information in API documentation...
Edit:
This can influence the usage or not for checked or unchecked exceptions.
What do you think ? value limits and API, do they belong together or not ?
I think they can belong together but don't necessarily have to belong together. In your scenario, it seems like it makes sense that the limits are documented in such a way that they appear in the generated API documentation and intellisense (if the language/IDE support it).
I think it does depend on the language as well. For example, Ada has a native data type that is a "restricted integer", where you define an integer variable and explicitly indicate that it will only (and always) be within a certain numeric range. In that case, the datatype itself indicates the restriction. It should still be visible and discoverable through the API documentation and intellisense, but wouldn't be something that a developer has to specify in the comments.
However, languages like Java and C# don't have this type of restricted integer, so the developer would have to specify it in the comments if it were information that should become part of the public documentation.
I think those kinds of boundary conditions most definitely belong in the API. However, I would (and often do) go a step further and indicate WHAT those null values mean. Either I indicate it will throw an exception, or I explain what the expected results are when the boundary value is passed in.
It's hard to remember to always do this, but it's a good thing for users of your class. It's also difficult to maintain it if the contract the method presents changes (like null values are changed to no be allowed)... you have to be diligent also to update the docs when you change the semantics of the method.
Question 1
Do you often see in API documentation (as in 'javadoc of public functions' for example) the description of "value limits" as well as the classic documentation?
Almost never.
Question 2
My only concern when I want to use this function is: what should I expect in term of parameters and return values ? That is all I need to know to safely setup my parameters and safely test the return value, yet I almost never see that kind of information in API documentation...
If I used a function not properly I would expect a RuntimeException thrown by the method or a RuntimeException in another (sometimes very far) part of the program.
Comments like #param aReaderNameRegexp filter in order to ... (can be null or empty) seems to me a way to implement Design by Contract in a human-being language inside Javadoc.
Using Javadoc to enforce Design by Contract was used by iContract, now resurrected into JcontractS, that let you specify invariants, preconditions, postconditions, in more formalized way compared to the human-being language.
Question 3
This can influence the usage or not for checked or unchecked exceptions.
What do you think ? value limits and API, do they belong together or not ?
Java language doesn't have a Design by Contract feature, so you might be tempted to use Execption but I agree with you about the fact that you have to be aware about When to choose checked and unchecked exceptions. Probably you might use unchecked IllegalArgumentException, IllegalStateException, or you might use unit testing, but the major problem is how to communicate to other programmers that such code is about Design By Contract and should be considered as a contract before changing it too lightly.
I think they do, and have always placed comments in the header files (c++) arcordingly.
In addition to valid input/output/return comments, I also note which exceptions are likly to be thrown by the function (since I often want to use the return value for...well returning a value, I prefer exceptions over error codes)
//File:
// Should be a path to the teexture file to load, if it is not a full path (eg "c:\example.png") it will attempt to find the file usign the paths provided by the DataSearchPath list
//Return: The pointer to a Texture instance is returned, in the event of an error, an exception is thrown. When you are finished with the texture you chould call the Free() method.
//Exceptions:
//except::FileNotFound
//except::InvalidFile
//except::InvalidParams
//except::CreationFailed
Texture *GetTexture(const std::string &File);
#Fire Lancer: Right! I forgot about exception, but I would like to see them mentioned, especially the unchecked 'runtime' exception that this public method could throw
#Mike Stone:
you have to be diligent also to update the docs when you change the semantics of the method.
Mmmm I sure hope that the public API documentation is at the very least updated whenever a change -- that affects the contract of the function -- takes place. If not, those API documentations could be drop altogether.
To add food to yours thoughts (and go with #Scott Dorman), I just stumble upon the future of java7 annotations
What does that means ? That certain 'boundary conditions', rather than being in the documentation, should be better off in the API itself, and automatically used, at compilation time, with appropriate 'assert' generated code.
That way, if a '#CheckForNull' is in the API, the writer of the function might get away with not even documenting it! And if the semantic change, its API will reflect that change (like 'no more #CheckForNull' for instance)
That kind of approach suggests that documentation, for 'boundary conditions', is an extra bonus rather than a mandatory practice.
However, that does not cover the special values of the return object of a function. For that, a complete documentation is still needed.