| Access | Constructor and Description |
|---|---|
| public | RuntimeReferencePropertyInfoImpl(RuntimeClassInfoImpl classInfo, PropertySeed<Type, Class<T>, Field, Method> seed)
|
| acc | back to summary |
|---|---|
| private final Accessor<BeanT, ValueT> acc | |
| RuntimeReferencePropertyInfoImpl | back to summary |
|---|---|
| public RuntimeReferencePropertyInfoImpl(RuntimeClassInfoImpl classInfo, PropertySeed<Type, Class<T>, Field, Method> seed) | |
| elementOnlyContent | back to summary |
|---|---|
| public boolean elementOnlyContent() Implements org. Doc from org. Returns true if this property has an element-only content. False otherwise.
| |
| getAccessor | back to summary |
|---|---|
| public Accessor Implements org. Doc from org. Gets the Even for a multi-value property, this method returns an accessor to that property. IOW, the accessor works against the raw type. This methods returns unoptimized accessor (because optimization accessors are often combined into bigger pieces, and optimization generally works better if you can look at a bigger piece, as opposed to individually optimize a smaller components)
| |
| getElements | back to summary |
|---|---|
| public Set Overrides org. Implements org. Doc from org. Returns the information about the possible elements in this property. As of 2004/08/17, the spec only allows you to use different element names when a property is a collection, but I think there's really no reason to limit it there --- if the user wants to use a different tag name for different objects, I don't see why this can be limited to collections. So this is a generalization of the spec. We always allow a property to have multiple types and use different tag names for it, depending on the actual type. In most of the cases, this collection only contains 1 item. So the runtime system is encouraged to provide a faster code-path that is optimized toward such cases.
| |
| ref | back to summary |
|---|---|
| public Set Overrides org. Implements org. Doc from org. List of
| |