Please expand your NgxsFormPluginModule description on gitbook.
I just implemented a reactive forms example with #ngxs/form-plugin.
It works great, but it was a bit of a struggle to get it to work; because it was not clear to me that the form state must have these specific properties:
model: YourFormModel,
dirty: boolean,
status: string,
errors: {}
Maybe you could add an explanation of these properties and their intended use?
What are the possible values for status, or is this up to the developer to define?
What type of object is errors and what is it used for? It appears to be empty even when validation fails. errors would suggest it is an array, but the example defines the default as an object?
I am posting this as a question because of your answer here: Where is it best to post questions about ngxs?
status field is supposed to store latest status of FormGroup.
You can see the code that is responsible for its update here.
The possible values for status are defined here.
errors is supposed to contain validation errors for the whole form group.
Its type is ValidationErrors since it's supposed to copy errors from the corresponding form group.
The code responsible for its update is supposedly here.
But there's an unsolved issue with filling it with actual error data., so it's not available yet and you'll have to rely on controls' error data.
Related
when getting back references from Yammer through the dev api, they can be of a few different types. Is there any documentation somewhere that describes the JSON model of returned objects?
Right now I have got the following from just reading the returned JSON.
Type:
- "user"
- "guide"
- "group"
- "thread"
- "topic"
But there could be other types I'm not expecting which could be sent in the future. Is there a list somewhere that describes indepth all the possible return types from the Yammer API?
There's not currently any documentation resource that will provide that information. It's also possible for additional reference types to be added later.
To deal with references robustly, you'll need to add code to handle the reference types you know about and do something reasonable for reference types you don't recognize.
The something reasonable may vary, but a good start would be to somehow log the reference and otherwise ignore it.
I'm trying to understand the plug-in sample from here.
There's this condition:
// The InputParameters collection contains all the data passed in the message request.
if (context.InputParameters.Contains("Target") &&
context.InputParameters["Target"] is Entity)
Speaking generally, not just with regard to this sample, on what prior knowledge should I base my decision to access a specific property? How could I have known to test whether the InputParameters contains a "Target" key (I assume I'm not supposed to guess it)?
And on what basis could I have known to ask whether the "Target" mapped value is of Entity type, and not some other type?
I found this post from 2 years ago, and I've found this webpage, saying (emphasis is mine):
Within a plugin, the values in context.InputParameters and
context.OutputParameters depend on the message and the stage that you
register the plugin on. For example, "Target" is present in
InputParameters for the Create and Update messages, but not the
SetState message. Also, OutputParameters only exist in a Post stage,
and not in a Pre stage. There is no single source of documentation
that provides the complete set of InputParameters and OutputParameters
by message and stage.
From my searchings, a single source still doesn't exist, but maybe the possible values can be found using the Dynamics Online platform, somewhere deep down the Settings menu, maybe? Any source would be great.
I know this is an "old" question that already has been answered, but I think this can be helpful. I've built a small web page that contains all the messages with all the Input/Output parameters. You can access it from here:
The best practice for doing this is to use a strongly typed approach. If, for example, you want to know which propertes are available on a CreateRequest, you would do:
var createReq = new CreateRequest() { Parameters = context.InputParameters };
createReq.Target; // Has type Entity
Take a look at the full blog post explaining this approach: Tip: Proper handling of Plugin InputParameters
Original answer:
It depends on which request we are talking about. See Understand the data context passed to a plug-in on MSDN.
As an example, take a look at CreateRequest. One property of
CreateRequest is named Target, which is of type Entity. This is the
entity currently being operated upon by the platform. To access the
data of the entity you would use the name “Target” as the key in the
input parameter collection. You also need to cast the returned
instance.
Note that not all requests contain a Target property that is of type
Entity, so you have to look at each request or response. For example,
DeleteRequest has a Target property, but its type is EntityReference.
In summary: Look at the actual request, e.g the CreateRequest.
In 2011 someone actually generated typed properties based on the message type. Kind of neat: https://xrmpalmer.wordpress.com/2013/05/27/crm2011-plugin-inputparameter-and-outputparameter-helper/
It would show you want parameters are possible per message.
Let's say I want to perform custom logic only, say, when a user's verified field changes from false to true (in order to make sure they are allowed to be performing this operation). Is there a way in Cloud Code to see what the 'current', i.e. about-to-be-overwritten value of a field is?
I would look at changedAttributes(), previousAttributes() and previous("columnName") to see if these have been exposed in the beforeSave handler yet.
Update note: none of those methods help.
The only other option I've seen in some older questions is to check object.existed() and in that case do a get() request to load the original values before the save. Obviously this causes 2 API requests per save.
It would be great to hear back if the changed/previous methods work.
Update
I have since done some more thorough testing, and the only option is to get() the previous version of the record. Nothing else works. This of course requires that you do it in the before-save handler.
I am in reference to the following method from BindingResult:
BindingResult.html#resolveMessageCodes(java.lang.String, java.lang.String)
I am trying to figure out the difference between an error code and a message code. Can someone please provide an example, especially one that would illustrate why there could be several message codes for a given error code?
Because web applications are internationalized, when you reject an object and want to have a message displayed for it, you don't use a hardcoded text because that will show the same no matter the language.
Instead, you specify an error code that later server as a key to retrieving the proper message from the bundles (and now the error code is a message code from the point of view of the method that must find the proper message text).
Your error code resolves to more message codes because Spring (based on the implementation) adds some additional ones for you. Here is a snippet from the Spring documentation:
[...] What error codes it registers is determined by the MessageCodesResolver that is used. By default, the DefaultMessageCodesResolver is used, which for example not only registers a message with the code you gave, but also messages that include the field name you passed to the reject method. So in case you reject a field using rejectValue("age", "too.darn.old"), apart from the too.darn.old code, Spring will also register too.darn.old.age and too.darn.old.age.int (so the first will include the field name and the second will include the type of the field); this is done as a convenience to aid developers in targeting error messages and suchlike. [...]
The last statement is the reason there are more message codes, to have control on the message that is displayed to the user, from a generic one (e.g. "Value required") to a more specific one given the context (e.g. "A value is required for field XXX").
The javadoc for DefaultMessageCodesResolver explains it further and gives an example:
For example, in case of code "typeMismatch", object name "user", field "age":
try "typeMismatch.user.age"
try "typeMismatch.age"
try "typeMismatch.int"
try "typeMismatch"
This resolution algorithm thus can be leveraged for example to show specific messages for binding errors like "required" and "typeMismatch":
at the object + field level ("age" field, but only on "user");
at the field level (all "age" fields, no matter which object name);
or at the general level (all fields, on any object).
I realize this is kind of "Stripes 101", but I guess I skipped that class.
I'd like to use the code that drops the "error" class into the field
tag class strings as the primary way to indicate missing required
fields. I'd then like to show a single error message along with any
other errors (like fields supplied with improper values).
Thus, the error info on the page might look like:
Sorry for the trouble, but:
1. Please supply values for all indicated required fields.
2. Please supply a numeric value for Zip Code.
etc.
I suppose I could go through the validation errors, look for ones for
fields where the value is empty, and make the assumption that those
were the required field errors. However, if I take those errors out
of the set, then I suspect that the page will no longer be able to
mark the erroneously-missing fields with the "error" class.
This seems like something likely to be pretty easy, but I can't find
any specific examples. Maybe I can do it all in the .jsp code; I'll start looking into that.
The DefaultActionBeanPropertyBinder adds an instance of ScopedLocalizableError with the default scope value of "validation.required" when a required field is missing.
So you coult probably write a tag similar to the stripes errors tag, but which collapes all the instances of ScopedLocalizableError having a default scope of "validation.required" to a single error message.