I have created an ontology using Protégé. Using Jena, I am creating an individual and assigning values for its properties. Datatype properties can be created using getOntProperty(String uri), but using the same method I cannot create object properties. Which method can be used to create object properties and add values for an object property?
getOntProperty(String) is an OntModel method for creating or retrieving properties from an ontology, not for making property assertions about Individuals. For datatype properties, you should probably be using getDatatypeProperty(String) instead. For object properties, you should use getObjectProperty(String). All of these methods are described in the documentation. Once you have a property, you can use the methods that an Individual inherits from Resource to add properties values. In particular, you'd want the addProperty and addLiteral methods.
Related
I have a command object that I want to convert into a domain object.
However, the object I want to convert the command object into may be one of two domain classes (they're both derived classes), and I need to do it in a service (which is where, based on other data, I decide which type of object it should be bound to). Is this possible and what's the best way to do this? bindData() only exists in a controller.
Do I just have to manually map command object parameters to the appropriate domain object properties? Or is there a faster/better way?
If the parameters have the same name, then you can use this question to copy the values over. A quick summary can be as follows.
Using the Grails API
You can cycle through the properties in a class by accessing the properties field in the class.
object.properties.each { property ->
// Do something
}
You can then check to see if the property is present in the other object.
if(otherObject.hasProperty(property) && !(key in ['class', 'metaClass']))
Then you can copy it from one object to the other.
Using Commons
Spring has a really good utility class called BeanUtils that provides a generic copy method that means you can do a simlple oneliner.
BeanUtils.copyProperties(object, otherObject);
That will copy values over where the name is the same. You can check out the docs here.
Otherwise..
If there is no mapping between them, then you're kind of stuck because the engine has no idea how to compare them, so you'll need to do it manually.
I have custom ActionMethodSelectorAttribute. Is it possible to read the model properties and it's value in there?
How are discrepancies between the Core Data Editor and the custom NSManagedObject subclass handled by Xcode?
For instance, let's say in the editor I have and Entity called Person with attributes firstName and age. I then create an NSManagedObject subclass of Person from the editor and in the header of the subclass I add the attribute lastName but I don't update the editor with this new attribute.
Depends somewhat on exactly how you define the property, but usually it will be treated like a transient property, so its value will not be set when the object is retrieved from the store unless you write some custom code to set it, nor will Core Data make any attempt to save it to the store. Also you won't be able to use the property in any fetch or sort predicate that results in core data generating sqlite SQL calls.
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.
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.