RE: [ve-dev] No Write JCMMethod found warning

["Janak Mulani" <janak.mulani@xxxxxxxxx>]

Hi Rich,
--- RLK ----
I still suggest actually changing it to not be containment. The entire Java
model in ve is expecting it to be in "properties" and not contained in
another java instance. I think you are buying trouble by doing other wise.

--- JMM ----

I understand your suggestion, but this spec has been a legacy for me from VE
0.5 and I have been living with it. Aligning our container-contained model
to Swing VE will entail too much change, but I will have to bite the bullet
sometime.

Moreover, making "containment=false" for "containemnt" SF of a ULCComponent
creates another problem for me:

It generates a local var in the getter of ULCComponent (which becomes a
child in a container) for the IJavaInstance that holds the layout
attributes. Also it creates "ulcComponent.null(var for
IJavaObjectInstance)". This is not valid ULC code because as I said earlier,
this IJavaObjectInstance is not a class of ULC, it is a class for storing
layout attrs in VE model only.

I hope this explains my dilemma.

Thanks and regards,

Janak

----------------------------------

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

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev