I was reading DWARFv4 spec and came across attribute DW_AT_endianity.
Correct me if my understanding is wrong.
As per spec, Two of the tag values TAG_variable and TAG_base_type both can have that attribute.
But as far as, i understand when you create a TAG_variable you have to pass the "Type", which can be of TAG_base_type(others are also possible).
So my question is if we are setting DW_AT_endianity on TAG_variable, why TAG_base_type also supports that attribute.
In other words every variable is of some type and can have that attribute, so why need attribute support for both type and variable?
The DW_AT_endianity attribute was the response to a proposed C compiler extension allowing the "creation of data in both big and little endian formats". It appears that the attribute was intended for base types (like this example) or structs/unions (like this one). Using the same attribute for both a simple variable and its underlying base type would, as you say, be redundant — note that the attribute is optional (see DWARF 4, sections 4.1.12 and 5.1).
Related
I do understand that Xodus' Entity Store provides StoreTransaction.find(..) which matches properties with the exact provided value and StoreTransaction.findStartingWith(..) which matches properties beginning with the provided value.
What I don't see is a StoreTransaction.findContains(..) or a LIKE of any sort. How would I approach such a search?
In version 1.3.232, there is no such. It makes sense to file a feature request.
I'm developing own custom field type in JIRA.
My class is very simple, it extends GenericTextCFType.
My goal is to store some identifier (ID) of field value in database but to show human-readable caption of the field value on Issue form.
I searched methods of GenericTextCFType class and found method getSingularObjectFromString, and I don't understand, what it does.
JIRA javadoc says: "Returns a Singular Object, given the string value as passed by the presentation tier"
But what is the Singular Object and what is it needed for?
Yes, it's not a great name. I wrote about it in detail in "Practical JIRA Plugins"
(O'Reilly). Here's an extract from there describing many of the methods in detail (sorry about the formatting). The book also has worked examples available at https://bitbucket.org/mdoar/practical-jira-plugins
CustomFieldType Methods
The example’s custom field type class will implement the CustomFieldType interface as usual, but instead will extend a class higher up in the inheritance hierarchy than NumberCFType. The class we will extend is AbstractCustomFieldType and it’s at the root of most classes that implement CustomFieldType.
The methods in the CustomFieldType interface with “SingularObject” in their name refer to the singular object, in this example a Carrier object. All other methods in JIRA 4 custom fields that refer to an Object are referring the transport object, e.g., a Collection of Carrier objects. JIRA 5 removed the use of Object in most custom field methods.
For more information about what changed in JIRA 5.0 with custom fields see https://developer.atlassian.com/display/JIRADEV/Java+API+Changes+in+JIRA+5.0#JavaAPIChangesinJIRA5.0-CustomFieldTypes. There were some major changes in the class hierarchy, and most classes now have a Java generic as a parameter instead of just using an Object as before.
There are two objects that are typically injected into the constructor of a custom field type’s class. The first is a CustomFieldValuePersister persister object, which is what will actually interact with the database. The second is a GenericConfigManager object that is used for storing and retrieving default values for the custom field. Other objects are injected into the constructor as needed—for example, the DoubleConverter in Example 2-2.
The first set of methods to consider are the ones that the custom field type uses to interact with the database in some way.
getSingularObjectFromString()
This method converts a string taken from the database such as “42.0###The answer” into a Carrier object. A null value means that there is no such object defined.
Fields with Multiple Values
Collection<Carrier> getValueFromIssue(CustomField field, Issue issue)
This is the main method for extracting what a field contains for a given issue. It uses the persister to retrieve the values from the database for the issue, converts each value into a Carrier object and then puts all the Carrier objects into a trans- port object Collection. A null value means that this field has no value stored for the given issue. This is one of the methods that used to return an Object before JIRA 5.0
createValue(CustomField field, Issue issue, Collection<Carrier> value)
updateValue(CustomField field, Issue issue, Collection<Carrier> value)
These methods create a new value or update an existing value for the field in the given issue. The persister that does this expects a Collection of Strings to store, so both of these methods call the method getDbValueFromCollection to help with that.
getDbValueFromCollection()
A private convenience method found in many custom field type classes, sometimes with a different name. It is used to convert a transport object (e.g., a Collection of Carrier objects) to a Collection of Strings for storing in the database.
setDefaultValue(FieldConfig fieldConfig, Collection<Carrier> value)
Convert a transport object (a Collection of Carrier objects) to its database repre- sentation and store it in the database in the genericconfiguration table.
Collection<Carrier> getDefaultValue(FieldConfig fieldConfig)
Retrieve a default value, if any, from the database and convert it to a transport object (a Collection of Carrier objects). The FieldConfig object is what represents the context of each default value in a custom field.
The next set of methods to consider are the ones that interact with a web page in some way. All values from web pages arrive at a custom field type object as part of a Custom FieldParams object, which is a holder for a Map of the values of the HTML input elements.
validateFromParams(CustomFieldParams params, ErrorCollection errors, FieldConfig config)
This is the first method that is called after a user has edited a custom field’s value. Any errors recorded here will be nicely displayed next to the field in the edit page.
getValueFromCustomFieldParams(CustomFieldParams customFieldParams)
This method is where a new value for a field that has been accepted by validate FromParams is cleaned and converted into a transport object. The custom FieldParams object will only contain strings for the HTML elements with a name attribute that is the custom field ID—e.g., customfield_10010. A null value means that there is no value for this field.
getStringValueFromCustomFieldParams(CustomFieldParams parameters)
This method returns an object that may be a String, a Collection of Strings or even a CustomFieldParams object. It’s used to populate the value variable used in Chapter 3: Advanced Custom Field Types Velocity templates. It’s also used in the Provider classes that are used by custom field searchers.
String getStringFromSingularObject(Carrier singularObject)
This method is not the direct opposite of getSingularObjectFromString as you might expect. Instead, it is used to convert a singular object (Carrier) to the string that is used in the web page, not to the database value. The returned String is also sometimes what is stored in the Lucene indexes for searching (“More Complex Searchers” on page 57). The singular object was passed into this method as an Object before JIRA 5.0.
The final set of CustomFieldType methods to consider are:
Set<Long> remove(CustomField field)
This method is called when a custom field is entirely removed from a JIRA instance, and returns the issue ids that were affected by the removal. The correct method to use for deleting a value from a field is updateValue.
String getChangelogValue(CustomField field, Object value)
String getChangelogString(CustomField field, Object value)
These methods are how the text that is seen in the History tab of an issue is gen- erated. When a custom field of this type changes, these methods are called with the before and after values of the field. The difference between the two methods is that the if the value later becomes invalid, the string will be shown instead (https://developer.atlassian.com/display/JIRADEV/Database+Schema#DatabaseSchema-ChangeHistory).
extractTransferObjectFromString()
extractStringFromTransferObject()
These methods are not from the CustomFieldType interface but they exist in the standard Multi fields for use during project imports.
Other Interfaces
There are a few other interfaces that are commonly implemented by custom field types.
ProjectImportableCustomField
The getProjectImporter method from this interface is used to implement how the custom field is populated during importing a project from an XML backup. If you don’t implement this interface then project imports will not import values for your custom field.
MultipleCustomFieldType
MultipleSettableCustomFieldType
These two interfaces are used by custom fields with options and that furthermore can have more than one option. For these classes, the values can be accessed using the Options class, which is a simple subclass of a Java List. These interfaces are not really intended for use by general-purpose multiple value custom field types.
Fields with Multiple Values | 41
SortableCustomField
This interface contains a compare method for comparing two singular objects. This is used by the Issue Navigator when you click on a column’s heading to sort a page of issues. This is actually a slower fallback for custom fields that don’t have a searcher associated with them (see Chapter 4).
RestAwareCustomFieldType
RestCustomFieldTypeOperations
These two interfaces are how the JIRA REST API knows which fields can be retrieved or updated. New in JIRA 5.0.
In MVC if you want to create an editor for a property or a display for you property you do something like that:
#Html.EditorFor(m=> m.MyModelsProperty);
#Html.DisplayFor(m=> m.MyModlesProperty);
Why do we have to pass a delegate why can't we just pass the model's property directlly? e.g.:
#html.EditorFor(Model.MyModlesProperty);
The reason for this is because of Metadata. You know, all the attributes you could put on your model, like [Required], [DisplayName], [DisplayFormat], ... All those attributes are extracted from the lambda expression. If you just passed a value then the helper wouldn't have been able to extract any metadata from it. It's just a dummy value.
The lambda expression allows to analyze the property on your model and read the metadata from it. Then the helper gets intelligent and based on the properties you have specified will act differently.
So by using a lambda expression the helper is able to do a lot more things than just displaying some value. It is able to format this value, it is able to validate this value, ...
I'd like to add, that besides the Metadata and making the Html helper strongly typed to the Model type, there's another reason:
Expressions allow you to know the name of the property without you hard coding strings into your project. If you check the HTML that's produced by MVC, you'll see that your input fields are named "ModelType_PropertyName", which then allows the Model Binder to create complex types that are passed to your Controller Actions like such:
public ActionResult Foo(MyModel model) { ... }
Another reason would be Linq to SQL. Expression Trees are the magic necessary to convert your Lambdas to SQL queries. So if you were to do something like:
Html.DisplayFor(p => p.Addresses.Where(j => j.Country == "USA"))
and your DbContext is still open, it would execute the query.
UPDATE
Stroked out a mistake. You learn something new every day.
The first example provides a strongly-typed parameter. It forces you to choose a property from the model. Where the second is more loosely-typed, you could put anything in it, even something that isn't valid property of the model.
Edit:
Surprisingly, I couldn't find a good example/definition of strong vs loose typing, so I'll just give a short example regarding this.
If the signature was #html.EditorFor(string propertyName); then I could make a typo when typing in the name and it would not be caught until run-time. Even worse, if the properties on the model changed, it would NOT throw a compiler error and would again not be detected until run-time. Which may waste a lot of time debugging the issue.
On the other hand with a lambada, if the model's properties changed you would get a compiler error and you would have to fix it if you wanted to compile your program. Compile-time checking is always preferred over run-time checking. This removes the chance of human error or oversight.
I was going to implement a custom DisplayAttribute in order to allow dynamic display values based on model values, but I can't because DisplayAttribute is sealed.
Before I go off and write my own customer attribute that emulates the behavior of DisplayAttribute, can anybody think of why this is sealed? I'm assuming there is a reason behind it, and if so, that may be the same reason I shouldn't try to "hack" around this limitation by rolling my own.
I'm not asking anyone to read Microsoft's mind, I'm just hoping someone already knows the by-design reason it's sealed, so that I can take that into account when rolling (or avoiding) my own implementation.
In general it is considered best practice to seal attributes. FxCop has a rule about it, defined here. From that page:
The .NET Framework class library provides methods for retrieving custom attributes. By default, these methods search the attribute inheritance hierarchy; for example Attribute.GetCustomAttribute searches for the specified attribute type, or any attribute type that extends the specified attribute type. Sealing the attribute eliminates the search through the inheritance hierarchy, and can improve performance.
Many of the MVC attributes (ActionFilter, etc) are unsealed because they are specifically designed to be extended, but elements in the DataAnnotations namespace are not.
Not exactly what you asked, but following your intent...
You can still allow for dynamic display values, you just wont extend the DisplayAttribute.
Instead, you can implement your own IModelMetadataProvider which could contain any logic needed to create dynamic display values.
Brad Wilson, from the ASP.NET MVC team, has a good article and sample of this on his blog: http://bradwilson.typepad.com/blog/2010/01/why-you-dont-need-modelmetadataattributes.html
In my understanding, the ViewModel pattern was designed to pass all the relevant data to View because 1) the view shouldn't perform any data retrieval or application logic and 2) it enables type-safety, compile-time checking, and editor intellisense within view templates.
Since dynamic expressions are defined at runtime, does this mean we don't get any of the 2)'s goodies?
You do not lose any of the existing functionality. You can still have a strongly-typed view such that when you access the Model property it will be of your specified type. The only thing that is added is a shorter way of accessing items in the ViewData dictionary.
Instead of the following
ViewData["MyData"]
you can have
View.MyData
Notice that you do not lose any type-safety because you never really had any. In the former case the key is a string (no certainty that it exists in the dictionary) and the value is an object so unless you cast it you can't do that much with it. In the latter you also get no intellisense and the returned value must be cast to something useful.
In fact the implementation of View.MyData simply takes the property name ("MyData") and returns the value coming from the ViewData dictionary.
Arguably the one thing you lose is the ability to have spaces or other characters that are not legal C# identifiers in your key names.