[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [ve-dev] No Write JCMMethod found warning
|
Hi
Sri,
Should
this decoder extend AbstractExpressionDecoder? And then should I override
generate() method to return null and mark the _expression_ as
STATE_NO_SRC?
Is
this all or there is need to do more?
Thanks
and regards,
Janak
Hi Janak,
Since this is
something specific to ULCComponent and not with base java core, it
would
be better to create a special
decoder for ULCComponent, which when it sees the 'containment'
SF would return null as the source, and mark
the _expression_ in the state 'NO_SOURCE'
(CodeExpressionRef.STATE_NO_SRC) so
that codegen doesnt try to update the document etc. with it.
Regards,
Sri.
"Janak Mulani"
<janak.mulani@xxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx
01/24/2006 03:17 PM
|
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, Sri,
I am not using any special decoder for
ULCComponent (we have special decoder
for ULCContainers though).
As
you said:
"The problem is you are dropping somewhere into standard
decoders that
expect java objects to be in a member container. You will
have to bypass
those."
I guess, one way to do it would be to specify
"containment" SF in ignoreSF
in DefaultMethodTextGenerator. Is this right?
If so how do I go about it?
Or is there another way to bypass std
decoders?
Thanks and regards,
Janak
--- RLK ---
We do not
handle java objects not being a property or a member of a member
container.
The problem here is you are creating a java object. Does this
class
"CardPaneContainment" actually exist in the project's classpath, but
you
never use it other than as a holder of data temporarily in the model?
If
that is true it should not be an IJavaObject, it should an EMF object.
You
shouldn't use faked up java instances for storing intermediate model
data.
If you are not able to change to EMF object then you will need to
debug
through your decoders/helpers and find out why you are getting the
errors
and put your own decoders in their place. The problem is you are
dropping
somewhere into standard decoders that expect java objects to be in
a member
container. You will have to bypass those. I can't help on that. I
don't know
codegen well enough. You can't just ignore the messages. It
means you are
getting into code that you shouldn't be in for your code
pattern. Sorry but
this is beyond me.
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
_______________________________________________
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
