In an entity, I have an enumeration field which is translated in english and french.
In the same entity, I have a computed field that I am using as a toString, so I would like to build the computed field with the enumeration value translated in english or french, depending on the user's locale.
My question : in the getter of my computed field written in the extension of the entity, how could I get the user's locale and translate the enumeration value ?
You have to make your extension aware of its execution context. There are several interfaces that you can implement in your extensions so that they get injected with elements of their running context.
org.jspresso.framework.model.component.IComponentFactoryAware to receive an ICompoentFactory instance
org.jspresso.framework.security.ISubjectAware to receive the instance of the logged-in Subject
org.jspresso.framework.application.backend.session.IApplicationSessionAware to receive the current instance of IApplicationSession
org.jspresso.framework.model.entity.IEntityLifecycleHandlerAware to receive an instance of IEntityLifecycleHandler
In order to fulfill your use-case, the 4th interface must be implemented. Your extension will be injected with an instance of IEntityLifecycleHandler through the following method :
void setEntityLifecycleHandler(IEntityLifecycleHandler);
Just store this instance in your extension implementation as an instance parameter and use it afterwards in your code by safely casting it as a org.jspresso.framework.application.IController.
For instance :
public String getI18nLabel() {
String translationKey = "ENUM_NAME." + getComponent().getEnumValue();
IController controller = (IController) lifecycleHandler;
return controller.getTranslation(translationKey, controller.getLocale());
}
Just remember that the pattern for the I18N resource bundle key of enumerations is ${ENUM_NAME}.${ENUM_VALUE} which is computed as the translationKey local variable in the code above.
Related
What is the naming convention for boolean returning methods?
Using an 'is', 'has', 'should', 'can' in the front of method sound ok for some cases, but I'm not sure.
Is there a better way to name such methods?
for example: a function that checks card's validation. Should I call it isValidCard or cardValidation or another name?
(I didn't find it here: https://kotlinlang.org/docs/reference/coding-conventions.html)
Something about naming convention for properties in Kotlin, I know it's not for methods. But it's related:
From book Kotlin in Action (by Dmitry Jemerov & Svetlana Isakova) - section 2.2.1 Properties:
In Kotlin, properties are a first-class language feature, which entirely replaces fields and accessor methods.
Listing 2.5. Declaring a mutable property in a class:
class Person {
val name: String, // read only property: generates a field and a trivial getter
var isMarried: Boolean // writable property: a field, getter and a setter
}
Kotlin’s name property is exposed to Java as a getter method called
getName. The getter and setter naming rule has an exception: if the
property name starts with is, no additional prefix for the getter is
added and in the setter name, is is replaced with set. Thus, from
Java, you call isMarried().
For those using properties prefixed with can, should, etc. in mixed Kotlin/Java projects, you can also use #get:JvmName to make the generated Java method more idiomatic for Java clients.
For example, say you have a class like this:
class User(
#get:JvmName("canView")
val canView: Boolean
)
Without the annotation, Java clients would be forced to call user.getCanView(), but now they can call the more idiomatic user.canView().
Kotlin naming style assumes you use the Java naming conventions to the possible extend. I suggest you use this answer to the same question about Java.
UPDATE: they have released coding conventions
http://kotlinlang.org/docs/reference/coding-conventions.html
In JsonDeserialize annotation documentation the contentAs field is supposed to define the "Concrete type to deserialize content".
I tried to use this in combination, with either a Converter (via contentConverter field of the same annotation) or a JsonDeserializer (via contentUsing field of the same annotation), by extending either StdConverter or StdDeserializer, respectively, in an attempt to create an agnostic custom deserializer.
I cannot find a way to access the JsonDeserialize#contentAs information inside any of these two classes.
I am aware that the classes I extend from have a type parameter, I just put an Object class there. Documentation states
contentAs Concrete type to deserialize content (elements of a Collection/array, values of Maps) values as, instead of type otherwise declared. Must be a subtype of declared type; otherwise an exception may be thrown by deserializer.
Apparently I am applying the #JsonDeserializer annotation on a Collection of some persistable Class. I want to deserialize each such object, solely by knowing its id. Well, if I could only get that very type I defined in the #JsonDeserializer#contentAs field...
Can anyone tell me if this is possible anyhow?
I managed to implement the agnostic deserializer withou the use of #JsonDeserializer#contentAs after all.
After reading the javadocs of com.fasterxml.jackson.databind.JsonDeserializer I concluded that my custom deserializer should implement the com.fasterxml.jackson.databind.deser.ContextualDeserializer interface.
Inside the implementation of ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property)
I could finally get access to the class type of the content of the collection, which I applied the #JsonDeserialize annotation on,
by calling:
ctxt.getContextualType().getRawClass()
NOTE that the same call inside the implementation of com.fasterxml.jackson.databind.JsonDeserializer#deserialize(com.fasterxml.jackson.core.JsonParser, com.fasterxml.jackson.databind.DeserializationContext) returned null, hence the need of the aforementioned interface.
All I had to do then is store the returned class in a member field (of type Class< ? >) of the custom deserializer and use it in the execution of JsonDeserializer#deserialize()
The only thing that remains to check is whether an instance of this custom deserializer is shared between threads. I only did some minor checks; I used the same implementation for two different collections of different types. I observed that ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) was called once (among multiple deserialization invokations), for each distinct type that was going to be deserialized. After checking during debugging, it seems that the same deserializer object is used for the same type. In my case, since what I store in the member field is this type itself, I don't mind if the same deserializer is used for the same java type to be deserialized because they should contain the same value. So we 're clear on this aspect as well.
EDIT: It appears all I have to do is update the com.fasterxml.jackson.databind.deser.std.StdDeserializer#_valueClass value to the now known class. Since it is final and since the ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) returns a JsonSerializer object, which is actually used,
instead of returning "this" serializer I can create a new one, passing the discovered class in the constructor, which actually sets the StdDeserializer#_valueClass to the class I actually want, and I'm all set!
Finally, NOTE that I didn't have to use the #JsonDeserializer#contentAs annotationfield as I get the value from the ctxt.getContextualType().getRawClass() statement inside ContextualDeserializer#createContextual(DeserializationContext ctxt, BeanProperty property) implementation
I am learning from Stanford's CS193P course. In the class, Paul has a demo project, "Calculator", where he uses id as the type of a property. He intends to not use a specific class, because he does not want to create a new class and then he does not need to write documentation, and even when it is updated, he does not need to redesign the class. id can solve all these problems.
Is this a really a good way? id is the return type of the property, and used as the parameter type of another method. How does the caller know what id is, and how to provide the correct object? By reading code comments?
In general, is there any good reason to use id as a return type or parameter type in public API? (Except init and factory method, though even for those, instancetype is recommended.)
If your method returns a class that is a member of a class cluster, you should return id.
If you're returning an object whose class is opaque, isn't declared in a public header, you should return id. (Cocoa occasionally uses such objects as tokens or context data.)
Container classes should always accept and return their constituents as ids.
I want to make a custom getter that should return two fields of the model instead of one. I have the attribute name like first_name. And the getter I am making is
public function getFirstName(){
return 1;
}
And then I try to get it called in a CDetailView like this
'client.first_name:raw:Client',
But it returns the standard attribute of the model. How to do it right?
Yii's order of operations to retrieve an attribute is as follows:
AR attribute
public variable
custom getter
I'm not sure whether AR attributes or public variables are pulled first, but I do know that if either of them exist, your custom getter won't be called.
If you already have a first_name attribute (from AR), then you'll need to use a different name for your getter and use that.
Methods should tell objects what to do, for example:
circle.paint()
But if I tell an object to getSomething(), I would tell the object to get "something" (from anywhere) and not to return "something", what is the typical usage of get methods (getName() would return "name").
I think that it would be more correct to name the method returnSomething().
So is get (as used typically) a bad naming pattern?
The convention probably varies depending on the language you are using, in php (which doesn't support getter/setter methods) the following is quite common:
$myObject=>setSomething($value) - sets an internal variable of $myObject representing 'something' to $value
$myObject=>getSomething() - returns an internal variable of $myObject representing 'something'
This is less common in languages like C#, which support getter/setter methods, where you'd probably do the following:
public object Something {
get { return _something; }
set { _something = value; }
}
Then you can use dot syntax to access the private variable:
myObject.Something="something";
string value=myObject.Something;
I personally don't use Get prefix.
Only prefix I do use for methods that retrieves something is Is for "indicators".
E.g. payment.IsOverdue()
As for setter methods - those shouldn't exist.
Object state should be defined by itself through invoked behavior.
Get is not necessary because when we are asking for something, nouns should be used for naming.
Deamon, first of all I think this thing kinda depends on the language.Secondly, I've got this Method Naming Guidelines for you.
The following are examples of
correctly named methods.
RemoveAll()
GetCharArray()
Invoke()
I can also say that in the company I am working we always use names like GetSomething(), GetYourAcceptRateHigher() for our methods.