For the Dymos problems I work with, I have code that adds states, controls, etc. in bulk and then use the set_XXX_options() method to specify specific parameter values (e.g. opt=True). This is easy for Dymos phases, because each phase has a add_XXX() method and an associated set_XXX_options() method. However, the trajectory.add_parameter() method does an associated trajectory.set_parameter_options() method.
Is there a reason the set_parameter_options() method is not available for trajectory objects? Can it be added as a method?
This is a good point and there's no reason we can't add this method, and we should for API consistency.
In the mean time, you can access the parameter_options dictionary after add_parameter to change settings. For instance,
traj.add_parameter('foo', ...)
traj.parameter_options['foo']['opt'] = True
I'll add an issue to make this a part of the API.
Related
#WebInitParam is an annotation that goes at class level.
It defines initialization parameters for the servlet.
I would like to know, what is the difference between doing this and using static variables, and why do it the #WebInitParam way rather than using statics?
What does defining k/v pairs as #WebInitParams allow you to do that you couldn't do if you declared static variables instead?
I have looked and all I can find is a million people saying how to define #WebInitParams. Well yes that's the easy bit. It's what I can do with that that is really what is of interest.
Thanks very much.
From a "raison d'etre" perspective, the annotation exists as a better design and architecture alternative to just peppering a class with static fields. #WebInitParam is a self-documenting approach to the initialization parameters a servlet or filter class needs, available via web.xml as well. It serves this purpose for the end developers as well as the JavaEE platform as a whole.
Think about it this way: in a vanilla project, you have the option of hardcoding a bunch of parameters in the class as static fields, or defining the same parameters in a property file. Which would you pick? Under what circumstances?
From a purely functional angle, apart from the function of using the annotation to override defaults set in web.xml, one other major reason is that you will sometimes need to get a hold of those initialization parameters from another component in your application. Using the annotation essentially increases the visibility of the parameter. In JSF for example, the API allows you to retrieve FacesServlet initialization parameters with:
//get all the parameters
FacesContext.getCurrentInstance().getExternalContext().getInitParameterMap()
//get a specific parameter
FacesContext.getCurrentInstance().getExternalContext().getInitParameter("aParameter");
In JSF-2.3 , it gets even more convenient with the following CDI-enabled injection:
#InitParameterMap Map<String,String> servletParameterMap;
Bear in mind that because it's CDI, it means this facility is available throughout the JavaEE platform, not just in web applications/JSF.
It's going to be a hassle to retrieve init parameters if the only mechanism available is a static field in the servlet class - you'll need to obtain an instance of the filter or servlet to get the static fields in it.
Separately, one could make the argument that maybe one should favour context-params over servlet-params because then, you get even more flexibility that isn't tied to any given servlet. That's a separate matter entirely :)
I have a use case where I used different models for the GET and POST actions in my controller. This works great for my view, because most of the data goes into labels. The model for the GET method contains 10 properties, but the model for the POST method only needs 3.
This GET view renders a form, which only needs 3 of these properties, not all 10. Thus, the model for the POST method accepts a model class which contains only these 3 properties. Therefore, the ASP.Net MVC model binder populates the model class parameter on my POST method with only these 3 necessary properties, and all is well.
Here's the question: When I encounter some business rule violation in the POST method, and want to use ModelState.AddModelError, and re-display the original view, I no longer have the 7 properties that were not POSTed, as they were not part of the form, and are not part of the model class which this method takes as its parameter.
Currently, I'm calling into a builder to return an instance of the model class for the POST method, and have the GET method itself delegating to the same builder. So, in these cases, when there is some business rule violation in the POST method, I return a View("OriginalGetView", originalGetModel). How can I use ModelState.AddModelError in this case, in the POST method, if I want to send custom messages back to the view, using a completely different model class?
It seemed way too lazy to use the same model class for both the GET and POST methods, given that their needs were so different. What is the best practice here? I see a lot of people recommending to use the same model for both methods, and to POST all of the fields back from hidden form fields, but that just seems like a waste of bandwidth in the majority of cases, and it feels ugly to be sending things like "VendorName" back to the server, when I already have "VendorId".
I may be misunderstanding what you are trying to do, but make sure you aren't being penny-wise and pound foolish. I see you may only want to post the identifiers and not necessarily the descriptors. But it sounds like you have to re-display the view after posting...if so you can just access the model properties if you post the same model that is in the get. If you only post the identifiers, you have to spend time re-accessing the database to get the description values(i.e. vendorname as you describe) using the vendor id no? Wouldn't that also be extra processing? Like I said, I could be misunderstanding your post, but for consistency using the same view model for your view to get and post makes the most sense to me.
Hidden Inputs maybe the best solution here still I think, even on 2g you shouldn't create any lag unless unless the values of your Model properties are long strings or something encrypted or xml.
So your .cshtml would have this in it for the 4 properties not currently included in the form:
<form>
#Html.HiddenFor(m => m.Property1)
#Html.HiddenFor(m => m.Property2)
#Html.HiddenFor(m => m.Property3)
#Html.HiddenFor(m => m.Property4)
But you could also get the model state errors from the original posted model and recreate the ModelError state in your response model to get around using hidden inputs.
I just found this guide (not the answer with Green Checkmark but the highest upped Answer: ASP.NET MVC - How to Preserve ModelState Errors Across RedirectToAction?
Note: if you need to copy model properties from Model to another Model (of the same type or different type), in a cleaner way, check out AutoMapper.
Perhaps this could help with what you were trying to achieve - 'Model' level errors - which wouldn't need to attach to a specific field/property - but can be displayed in a Global area.
https://stackoverflow.com/a/53716648/10257093
I'm using ractivejs,I know angularjs's two way binding based "dirty check",but I don't know the principle of ractivejs,who knows?I want a detailed answer.
Ractive doesn't diff or check anything, it uses the declarative template to know exactly what needs to be updated.
Ractive constructs a virtualDOM based on the template. The templated portions of the virtual dom (things with {{...}} in them) register with the viewmodel using the keypaths they contain.
When a ractive.set(...) or one of the other data manipulation methods occurs, dependents are notified of the change (computations and expressions, upstream and downstream keypaths, as well as observers are also notified).
Ractive uses a runloop that batches the actual DOM changes for any set operation to occur at the end of the cycle.
In addition to API calls, Ractive offers twoway binding by default. This maps needed DOM events from form input controls to the API calls to set the data to which it is bound (via the specified keypath).
Ractive does offer the .update(keypath) and .updateModel(keypath) methods which can be used to flush changes from model to view, or view to model when it is not possible for Ractive to know about them, for example using a third-party widget library.
I have a form which is used for automatic journal postings.
On that form I have a Ok command button and in closeOk method of the form I call the method from my datasource table.
In the JournalCheckPost class's infoResult() method I want to determine if the method is called from my form. I know that it can be done with caller methods but I don't know how exactly it should be done technically.
It is bad practice to make a method depend on where it is called from.
What you can do is to pass an extra parameter to the LedgerJournalCheckPost and infoResult can then check that. This can be done by introducing a boolean flag and a parm method.
I think, there can be many situations:
You want to pass some parameters from form
You want to manipulate the form (for example refresh datasource after action is complete)
Something other
But in all the cases depending on particular form is not a very good idea.
In first case you can set parameters from code using parm methods, or, better pass parameters using the Args class
In the second you can cast Args.caller to some interface that contain all the methods you want and manipulate the form using that methods (see \Classes\SysFormRun_doRe usages for example)
I am currently using event handler subscriptions for database logging within AX2012 on the insert, update and delete methods, however the issue i have incountered is that these events are not being fired if the method is called via a doinsert, doupdate or dodelete, is there a way i can intercept these events?
You could instead override the aosValidateInsert, aosValidateUpdate and aosValidateDelete methods. I have included references to the official documentation, sadly it currently does not explain their intended usage.
As the names imply, the methods are called before the actual operation, which may or may not suit your needs.
Remember to return true!
Also beware that adding the methods make AX use record-by-record operations instead of using set operations for example in delete_from. Also you cannot disable that using skipDataMethods (but you can using skipAOSValidation).
doXXXX methods are used specifically to avoid running any logic associated with this XXXX action, so try to intercept them goes against the design pattern of this methods and their utilisation.
Have you tried the standard database logging which you can configure and query by X++ code? For example:
http://www.jaestevan.com/howto-consultar-el-registro-de-base-de-datos-mediante-x