Let's say I have DAC class with two fields. Boolean ( let's it's name is IsDateRequired ) and DateTime ( let's name it DateReceive ). Is it possibel to make field DateReceive required only in case if IsDateRequired equal to true?
To make field mandatory conditionally, you need to use PXDefaultAttribute.SetPersistingCheck<DAC.Field>(pxcache, data, PXPersistingCheck.<Value>) method in _RowSelected event handler.
PXPersistingCheck.Nothing will make field non-mandatory and PXPersistingCheck.Null/PXPersistingCheck.NullOrBlank will make field mandatory.
You need to make sure to have PXDefault attribute declared for the DAC field you are trying to make it mandatory conditionally. Without PXDefault attribute declared, static methods of PXDefaultAttribute will not have any impact.
Related
how to implement a state change in TFS 2012, when any fields are changed in that work item type.
I have a task work item type which is set to "proposed". When the field/fields are changed in task work item, state should be changed to "Active" automatically.
You need to customize the work item definition and add a rule to the field. Refer to this link for details: Working with Field Rules and Assign Conditional-Based Values and Rules
Depending on the data type of a field, you can set various
restrictions on what data can be entered into that field. For example,
you can define a default value, restrict what values users can
specify, and restrict who can update the value of the field. You may
want to apply a rule to a work item field for one or more of the
following reasons:
Specify the tooltip text that appears when a user hovers over a field in a work item form.
Require the value of a string field to match a pattern.
Make a field required or read-only, or make sure that it does not contain the same value as another field.
Clear a field, or restrict further modifications of a field.
Restrict who can modify the field.
Apply a rule to a field when the value of another field has changed or is assigned a specific value.
Update:
For System fields, there is some restriction for them. Refer to this link for details: Q: What rules can be applied to System fields?
Q: What rules can be applied to System fields? A: System fields have
Sytem.Name reference names, for example System.Title and System.State.
TFS restricts customization of these fields, except for these
instances: HELPTEXT rule can be assigned to all fields. READONLY rule
can be assigned to the State and Reason fields. Most rules can be
assigned to the Title, Assigned To, Description or Changed By System
fields.
That means, you cannot apply the rule to change the state in your case.
Let's say I have classes similar to domain classes in my application with some Long, Double, Date and String fields. These classes extend base class with some common fields and few common methods. Whenever I access class field (though getter) that is String, I want to make some changes to the value returned (for example remove html tags). Is there a better way than making implementations of getters for each fields of String type? What about inherited fields?
Don't change default getter/setter implementations created for you by Grails. You would definitely mess up your application in various places. Grails uses convention over configuration so getters/setters should definitely remain unchanged.
Create your own methods that return what you want: for a field title create method getStrippedTitle(). You can add this method to transients too.
If you change the value that's set, or return a value that's different from what was set, you'll confuse Hibernate. That's because when you load an instance from the database, Hibernate keeps the original data in its 1st-level cache, and returns a domain object instance to you. When you flush, it compares the current state with the original, and if it changed, it will push the changes to the database. So if you return a different value than what was set, but don't really change the value, Hibernate can't tell the difference.
You're much better off leaving the properties alone and creating methods that return altered data. One convention I've used is that if for example you have a String body field, you can access it via the property name body or the getter getBody(), but you can create a body() method that's unknown to Hibernate and returns whatever you want.
I have a class. At one point, I had set the properties of the class to [Required] using System.ComponentModel....
Okay, then I realized this was not needed. I have removed the required property but when I try to submit the form to an ActionResult the form does NOT post and still is trying to enforce the TextBoxFor(theModelProperty) to be populated.
I have deleted the "obj" folder, the "bin" folder, and also "Cleaned" the solutions. Still NO resolution.
I don't want to do a stupid workaround, I would like to do things correctly. Any idea why this occurs?
You have two options:
Set property as nullable,
Turn off required attribute for value
types (see this answer)
If you have value type properties. Client validation will always generate required validations. If you don't want required validation for value types make them nullable.
I'm making a Web Page with MVC and I would like to know if it's possible to set a field as nullable, I mean, the opposite of Required, because I want it to be an optional field.
Thank you.
All object types can be nullable, i.e. optional, for value types you can use either the type? notation or explicitly with Nullable<type>. If you don't provide a value to the ModelBinder for that property then it will receive NULL.
If you omit the [Required] attribute on the optional field in the model this will have the desired effect.
PLEASE NOTE: I've answered my own question with a link to an answer to a similar question. I'll accept that answer once I'm allowed to (unless anyone comes up with a better answer meantime).
I have a database column defined as NVARCHAR(1000) NOT NULL DEFAULT(N'') - in other words, a non-nullable text column with a default value of blank.
I have a model class generated by the Linq-to-SQL Classes designer, which correctly identifies the property as not nullable.
I have a TextAreaFor in my view for that property. I'm using UpdateModel in my controller to fetch the value from the form and populate the model object.
If I view the web page and leave the text area blank, UpdateModel insists on setting the property to NULL instead of empty string. (Even if I set the value to blank in code prior to calling UpdateModel, it still overwrites that with NULL). Which, of course, causes the subsequent database update to fail.
I could check all such properties for NULL after calling UpdateModel, but that seems ridiculous - surely there must be a better way?
Please don't tell me I need a custom model binder for such a simple scenario...!
Might be duplicate or something in the line of this:
MVC binding form data problem
I fear custom model binder will be necessary. ;)
You might want to use a partial class implementation of your entity that implements the on property changed handler for that particular property. When you detect that the property has been changed to NULL, simply change it to string.Empty. That way anytime NULL is assigned to the property it gets reset to the empty string.