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

[Srimanth Gunturi <sgunturi@xxxxxxxxxx>]

Hi Janak,
        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.
Regards,
Sri.

"Janak Mulani" <janak.mulani@xxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

01/24/2006 11:37 AM

Please respond to
Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>

To	"Discussions people developing code for the Visual Editor project" <ve-dev@xxxxxxxxxxx>
cc
Subject	RE: [ve-dev] No Write JCMMethod found warning

Hi Rich,

Thanks for your reply.


2. Our Model:
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 ---

Can this be ignored or is it harmful in anyway? How can I suppress this
warning? Should I specify SF "containemt"
in ignoreSF of DefaultMethodTextGenerator? If so how?

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