| Using ImpliedElementProperties [message #1172153] |
Tue, 05 November 2013 13:46  |
Eclipse User |
|
|
|
Hi,
I am trying to create a model that is similar to your NestedPropertiesInListGallery example.
In your example, the resulting list is an homogeneous ElementList of Employees.
In my case I am trying to model a heterogeneous ElementList of Actions.
I have an ImpliedElementProperty defined in one of my models as follows:
@Type(base = ActionBase.class, possible = { Subclass1.class, Subclass2.class, Subclass3.class, Subclass4.class, Subclass5.class })
@XmlListBinding(path = "actions")
ImpliedElementProperty PROP_ACTION_LIST = new ImpliedElementProperty( TYPE, "ActionList" );
ActionList getActionList();
When I try to add an item to the list, Sapphire calls StandardImpliedXmlElementBindingImpl.Init which throws an IllegalStateException because the number of types returned by the following call is greater than 1
if( property.service( PossibleTypesService.class ).types().size() > 1 )
{
throw new IllegalStateException();
}
When I step through the above call I get into the PossibleTypesService class.
The comment in this class states :
* Enumerates the possible child element types for a list or an element property. Each
* returned type is required to derive from the property's base type.
All of my subclasses are derived from the ActionBase class which implies to me that what I am doing should work.
Is this the case or am I misunderstanding something?
Thanks in advance for your help
|
|
|
|
|
|
| Re: Using ImpliedElementProperties [message #1173760 is a reply to message #1173703] |
Wed, 06 November 2013 13:47  |
| Eclipse User |
|
|
|
What I am after is to display a summary list of actions.
I have this working but I have run into another issue which I believe is caused by differences between ImpliedElementProperty and ElementProperty.
Here's what I have so far:
I fixed my ListProperty definition as follows
@Type(base = Action.class, possible = { CollectData.class, PromptAndWaitForResponse.class })
@Label( standard = "Action Summary" )
ListProperty PROP_ACTION_LIST = new ListProperty( TYPE, "ActionList" );
ActionList getActionList();
I've create the following models:
Please note the following two lines of code in the Action
//@Type(base = Instruction.class, possible = {PromptDigits.class, PromptReady.class})
//ElementProperty PROP_INSTRUCTION = new ElementProperty( TYPE, "Instruction" );
public interface ActionList extends Element {
ElementType TYPE = new ElementType(ActionList.class);
interface Action extends Element, HtmlElement
{
ElementType TYPE = new ElementType( Action.class );
@DefaultValue(text = "Default Action Name")
@Label(standard = "Action Name")
@Required
@ReadOnly()
ValueProperty PROP_ACTION_NAME = new ValueProperty(TYPE, "ActionName");
Value<String> getActionName();
interface Instruction extends Element
{
ElementType TYPE = new ElementType( Instruction.class );
@DefaultValue(text = "Default Name")
@Label(standard = "Instruction Name")
@Required
@ReadOnly()
ValueProperty PROP_NAME = new ValueProperty(TYPE, "Name");
Value<String> getName();
}
@Label(standard = "Instruction")
//@Type(base = Instruction.class, possible = {PromptDigits.class, PromptReady.class})
//ElementProperty PROP_INSTRUCTION = new ElementProperty( TYPE, "Instruction" );
@Type(base = Instruction.class)
ImpliedElementProperty PROP_INSTRUCTION = new ImpliedElementProperty( TYPE, "Instruction" );
Instruction getInstruction();
}
@Type( base = Action.class )
@Label( standard = "actions" )
ListProperty PROP_ACTIONS = new ListProperty( TYPE, "Actions" );
ElementList<Action> getActions();
}
public interface PromptDigits extends Instruction, Prompt {
ElementType TYPE = new ElementType(PromptDigits.class);
@DefaultValue(text = "Prompt Digits")
// Name of the Action
@Label(standard = "Instruction Name")
ValueProperty PROP_NAME = new ValueProperty(TYPE, "Name");
@Override
Value<String> getName();
}
My sdef for the ListProperty looks like:
<property-editor>
<child-property>ActionName</child-property>
<property>ActionList</property>
<child-property>Instruction/Name</child-property>
<child-property>
<hint>
<name>read.only</name>
<value>true</value>
</hint>
<property>ElementIdType</property>
</child-property>
<child-property>
<hint>
<name>read.only</name>
<value>true</value>
</hint>
<property>ElementIdValue</property>
</child-property>
<hint>
<name>read.only</name>
<value>true</value>
</hint>
</property-editor>
From the definitions above, I get the following list which is what I am after.
The problem I am running into now seems to be around implied element properties versus element properties.
With the above models, when I add a "CollectData" action to the list, the Instruction property is "unknown" at the time of creating the CollectData property.
I would like to be able to use a "With" part to allow the user to select the type of instruction that will be associated with the CollectData model.
If I change the following lines in the Action model from
@Type(base = Instruction.class)
ImpliedElementProperty PROP_INSTRUCTION = new ImpliedElementProperty( TYPE, "Instruction" );
to
@Type(base = Instruction.class, possible = {PromptDigits.class, PromptReady.class})
ElementProperty PROP_INSTRUCTION = new ElementProperty( TYPE, "Instruction" );
to make the Instruction Property an ElementProperty instead of an ImpliedElementProperty, I can do the following
If the instruction is an ImpliedElementProperty, I run into the xml binding issue from the original post for this topic. It also breaks my action summary list because I can no longer use
<child-property>Instruction/Name</child-property>
in the sdef.
|
|
|
|
|
| Re: Using ImpliedElementProperties [message #1175126 is a reply to message #1174966] |
Thu, 07 November 2013 09:45 |
| Eclipse User |
|
|
|
Quote:I don't want to edit anything in the the summary table. I just want to display the data
The cells in the table property editor are themselves property editors. Double click to edit data in place.
Quote:can you explain the difference between how Sapphire handles Element properties (Explicit?) versus Implied Element properites?
At model-level, a regular (or explicit) element property's child element must be explicitly created by an api call that can specify a type (hence the heterogeneous support); the child element can also be deleted. In contrast, the child of an implied element property is instantiated on first access. There is no api to create it explicitly and there is no way to delete it. Once you access it, it is there.
This has an implication on the matching UI patterns. The best way to understand it is to try the "with" construct on an implied element property and on a regular element property. In the first case you will not see any UI relating to the element property, the context just passes to the child element. In the second case, you will have controls to create and delete the element.
Quote:When should you typically use an ElementProperty versus and Implied Element property?
Implied element properties are used when the child element has no semantic meaning. That is, the model could be flattened without loosing any semantics. Regular element properties are used when the presense/absence of the child element in itself has a semantic meaning and the model could not be flattened without loosing those semantics.
|
|
|
Powered by
FUDForum. Page generated in 0.03594 seconds
Home