[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [ve-dev] No Write JCMMethod found warning
|
Hi Rich, Sri,
Thanks for the reply.
Is it ok ignore / live with this warning? Or is it harmful in anyway?
How can I suppress this warning? Can I specify SF "containemt" in ignoreSF
of DefaultMethodTextGenerator? If so how?
--- JMM --
In our model "containment" is SF of the child component. Our
Container-Contained relationship is direct
ULCContainer-components-ULCComponent and the contained component has the
"containment" feature set with a JavaInstance that holds layout attributes.
We do not have an intermdiate association object such as ConstrainComponent
like you have in Swing. Your Container-Contained relationship is indirect
SwingContainer-components-ConstraintComponent-component-SwingComponent
|---------------const
raint-IJavaInstance containing layout attr
Therefore for Swing VE the eContainer for constraint is Swing Container, but
for ULCVE eContainer for "containment" SF (which holds the layout attr
IjavaInstance) is the child component instead of the container in whose
method the "add" expression args map to attrs IJavaInstance.
And it is because of our direct Container-Contained relation that we have
"containment=true" for "containment" SF.
==== Sri ====
Looking at the stack trace it looks like the generation of one of the
expressions is failing for
some reason. ExpressionDecoders ask the DecoderHelper to generate the
content - if the real
DecoderHelper doesnt generate anything (null), the
SimpleAttributeDecoderHelper is asked to
give it a shot. In the stack trace the SimpleAttributeDecoderHelper is
failing because he cant find
a write method for the structural feature being set. If you debug at
AbstractExpressionDecoder.generate(EStructuralFeature, Object[]) you should
be able to see which
original DecoderHelper is failing and why.
--- RLK-- Again most of it is because of using containment="true". When you
use that, the properties is not contained in a member container. That means
it fails
the normal generate and dropped back to try the
SimpleAttributeDecoderHelper. But that failed because there is not set
method for the feature. To access this property requires a special decoder
helper. That is because it is a parm to the "add" instead of simple set
stmt. We use a special one for awt.Container (ContainerAddDecoderHelper)
This is the guy who handles the property on the set stmt.
--- JMM ----
On a ULCComponent we have SF "containment" which holds attributes of the
layout when a component is contained in a container:
<event:Add featureName="eStructuralFeatures">
<addedEObjects xsi:type="ecore:EReference" name="containment"
eType="ecore:EClass java:/java.lang#Object"
upperBound="1" changeable="true" unsettable="false"
containment="true">
</addedEObjects>
</event:Add>
-- RLK -- I don't know if this is the problem but you shouldn't have
containment="true". ALL of our code expects all java instances to be
contained as either "members" or "properties" in a MemberContainer. If a
property setting is not contained by a member (which is what JCMMethod is),
then I think it will fail.
--- JMM ---
In our case, the JavaInstance that stores the layout attributes does not
have corresponding code. Its attributes map to the arguments of the "add"
methof of the conatiner.
For instance take ULCCardPane.
When we add ULCButton to ULCCardPane we create an IJavaInstance for
class CardPaneContainment {
private String name:
public String getName() { ... }
public SetName(String s) {... }
}
The value of ULCButton's "containment" SF is set to an instance of
CardPaneContainment which has some "name".
Then, ULCCardPane's "component" SF is set to ULCButton.
The genearted code is as follows:
private ULCCardPane ulcCardPane = null; //
@jve:decl-index=0:visual-constraint="75,6"
private ULCButton ulcButton = null;
private ULCCardPane getUlcCardPane() {
if (ulcCardPane == null) {
ulcCardPane = new ULCCardPane();
ulcCardPane.setPreferredSize(new
com.ulcjava.base.application.util.Dimension(265,97));
ulcCardPane.addCard("ulcButton", getUlcButton());
// The first arg corresponds to "name" which is stored in the model as
feature
// of CardPaneContainment instance which is set as value of SF
"containment" on ULCButton
}
return ulcCardPane;
}
private ULCButton getUlcButton() {
if (ulcButton == null) {
ulcButton = new ULCButton();
}
return ulcButton;
}
--- RLK-- Are you generating these directly, or are you using a
RuledCommandBuilder? You should be using a RuledCommandBuilder.
ApplyAttributeSettingsCommand - sets "containment" SF on ULCButton
VCEPresetCommand - SF "component" on target ULCCardPane with value ULCButton
ApplyAttributeSettingsCommand - SF "component" on target ULCCardPane with
value ULCButton
--- JMM : The commands are generated using RuledCommand Builder.
It is during the last ApplyAttrSettingsCommnad that the above warning is
generated. Following is the stack trace:
SimpleAttributeDecoderHelper.generate(Object[]) line: 339
ObjectDecoder(AbstractExpressionDecoder).generate(EStructuralFeature,
Object[]) line: 210
CodeExpressionRef.generateSource(EStructuralFeature) line: 359
ExpressionRefFactory.createFromJVEModel(Object[]) line: 102
DefaultMethodTextGenerator(AbstractMethodTextGenerator).primGenerateAttribut
e(EStructuralFeature, BeanPart, Object[]) line: 218
DefaultMethodTextGenerator(AbstractMethodTextGenerator).generateAttribute(ES
tructuralFeature, BeanPart) line: 231
AbstractMethodTextGenerator$2.isSet(EStructuralFeature, Object) line: 262
JavaObjectInstance(JavaInstance).visitSetFeatures(FeatureValueProvider$Visit
or) line: 61
FeatureValueProvider$FeatureValueProviderHelper.visitSetFeatures(EObject,
FeatureValueProvider$Visitor) line: 53
AbstractMethodTextGenerator$1.generateFromFeatures(BeanPart) line: 253
DefaultMethodTextGenerator(AbstractMethodTextGenerator).generateForSetFeatur
es(BeanPart) line: 278
DefaultMethodTextGenerator(AbstractMethodTextGenerator).generateExpressionsC
ontent() line: 287
BeanPartFactory.generateInitMethod(BeanPart, IJavaObjectInstance,
CodeMethodRef, String, ICompilationUnit) line: 274
BeanPartFactory.createFromJVEModel(IJavaObjectInstance, ICompilationUnit)
line: 603
BeanDeclModel.lazyCreateBeanInstance(EObject) line: 279
BeanDeclModel.getABean(EObject) line: 298
BeanDecoderAdapter.addElement(Notification) line: 379
BeanDecoderAdapter.notifyChanged(Notification) line: 455
JavaObjectInstance(BasicNotifierImpl).eNotify(Notification) line: 229
EcoreEList$Dynamic(EcoreEList).dispatchNotification(Notification) line: 211
EcoreEList$Dynamic(NotifyingListImpl).addAllUnique(int, Collection) line:
423
EcoreEList$Dynamic(NotifyingListImpl).addAllUnique(Collection) line: 367
EcoreEList$Dynamic(BasicEList).addAll(Collection) line: 686
ApplyAttributeSettingCommand.execute() line: 92
Thanks and regards,
Janak
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
