Home » Eclipse Projects » GEF » CreationFactory and create commands
|
| Re: CreationFactory and create commands [message #167989 is a reply to message #167966] |
Sun, 13 February 2005 23:23   |
Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> i came across the following tip in the Redbook on GEF/EMF (top of page 107)
>
> Tip: Actually, your CreationFactory implementation does not need to create
> new model objects. We suggest only submitting the type of the new model
> object and creating it later in a Command.
>
> this certainly seems plausible. i was wondering if there's any examples of
> this pattern that i could look at. the GEF samples don't seem to use it.
>
> i need to create objects that depend on the location (model component) being
> clicked on. seems like this pattern may be the right way to go about it. has
> anyone tried this? any suggestions?
>
> regards,
>
> al
>
>
Well that makes no sense. Then what is the purpose of a CreationFactor
that does not create anything...
I pass the whole factory into my command. And let the command call on
the factory when it needs a new object.
CL
|
|
|
| Re: CreationFactory and create commands [message #168002 is a reply to message #167966] |
Mon, 14 February 2005 00:55 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The limitation of this tip is that if more than one editpolicy require
access to the object being created, you must use the CreateRequest to
manage/cache the creation. This is rare, but a common scenario would be if
a layout manager *only* setup constraint info, while a container editpolicy
performed the add.
"Al Major" <almajor@boxspoon.com> escreveu na mensagem
news:cunn70$c6g$1@www.eclipse.org...
>i came across the following tip in the Redbook on GEF/EMF (top of page 107)
>
> Tip: Actually, your CreationFactory implementation does not need to create
> new model objects. We suggest only submitting the type of the new model
> object and creating it later in a Command.
>
> this certainly seems plausible. i was wondering if there's any examples of
> this pattern that i could look at. the GEF samples don't seem to use it.
>
> i need to create objects that depend on the location (model component)
> being
> clicked on. seems like this pattern may be the right way to go about it.
> has
> anyone tried this? any suggestions?
>
> regards,
>
> al
>
>
|
|
|
| Re: CreationFactory and create commands [message #168059 is a reply to message #168002] |
Mon, 14 February 2005 02:28 |
 Al Major
Messages: 72
Registered: July 2009 |
Member |
|
|
does this limitation imply that the model object creation pretty much has to
be done in the CreateRequest as currently occurs?
in that case, it would appear that the preferred way to influence the
initial state of the created object would be to call setter functions,
either on the factory or on the created object, prior to calling
CreateRequest.getNewObject. presumably all of this would be done in one of
the LayoutEditPolicy.getCreateCommand overrides.
is this a reasonable way to proceed? or is there a better way to set the
state of the created model object?
passing the creation factory into the command as CL suggested would appear
to have the same limitation as the tip. the CreateRequest wouldn't have the
object in cache.
regards,
al
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cuostt$j1a$1@www.eclipse.org...
> The limitation of this tip is that if more than one editpolicy require
> access to the object being created, you must use the CreateRequest to
> manage/cache the creation. This is rare, but a common scenario would be
if
> a layout manager *only* setup constraint info, while a container
editpolicy
> performed the add.
>
> "Al Major" <almajor@boxspoon.com> escreveu na mensagem
> news:cunn70$c6g$1@www.eclipse.org...
> >i came across the following tip in the Redbook on GEF/EMF (top of page
107)
> >
> > Tip: Actually, your CreationFactory implementation does not need to
create
> > new model objects. We suggest only submitting the type of the new model
> > object and creating it later in a Command.
> >
> > this certainly seems plausible. i was wondering if there's any examples
of
> > this pattern that i could look at. the GEF samples don't seem to use it.
> >
> > i need to create objects that depend on the location (model component)
> > being
> > clicked on. seems like this pattern may be the right way to go about it.
> > has
> > anyone tried this? any suggestions?
> >
> > regards,
> >
> > al
> >
> >
>
>
|
|
|
| Re: CreationFactory and create commands [message #168114 is a reply to message #168059] |
Mon, 14 February 2005 04:27 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Could you give some concrete examples of what you are doing. I don't see
why the command couldn't "configure" the object created by the request.
"Al Major" <almajor@boxspoon.com> escreveu na mensagem
news:cup2jl$6t9$1@www.eclipse.org...
> does this limitation imply that the model object creation pretty much has
> to
> be done in the CreateRequest as currently occurs?
>
> in that case, it would appear that the preferred way to influence the
> initial state of the created object would be to call setter functions,
> either on the factory or on the created object, prior to calling
> CreateRequest.getNewObject. presumably all of this would be done in one of
> the LayoutEditPolicy.getCreateCommand overrides.
>
> is this a reasonable way to proceed? or is there a better way to set the
> state of the created model object?
>
> passing the creation factory into the command as CL suggested would appear
> to have the same limitation as the tip. the CreateRequest wouldn't have
> the
> object in cache.
>
> regards,
>
> al
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cuostt$j1a$1@www.eclipse.org...
>> The limitation of this tip is that if more than one editpolicy require
>> access to the object being created, you must use the CreateRequest to
>> manage/cache the creation. This is rare, but a common scenario would be
> if
>> a layout manager *only* setup constraint info, while a container
> editpolicy
>> performed the add.
>>
>> "Al Major" <almajor@boxspoon.com> escreveu na mensagem
>> news:cunn70$c6g$1@www.eclipse.org...
>> >i came across the following tip in the Redbook on GEF/EMF (top of page
> 107)
>> >
>> > Tip: Actually, your CreationFactory implementation does not need to
> create
>> > new model objects. We suggest only submitting the type of the new model
>> > object and creating it later in a Command.
>> >
>> > this certainly seems plausible. i was wondering if there's any examples
> of
>> > this pattern that i could look at. the GEF samples don't seem to use
>> > it.
>> >
>> > i need to create objects that depend on the location (model component)
>> > being
>> > clicked on. seems like this pattern may be the right way to go about
>> > it.
>> > has
>> > anyone tried this? any suggestions?
>> >
>> > regards,
>> >
>> > al
>> >
>> >
>>
>>
>
>
|
|
|
| Re: CreationFactory and create commands [message #168129 is a reply to message #168114] |
Mon, 14 February 2005 04:56 |
Al Major
Messages: 72
Registered: July 2009 |
Member |
|
|
unfortunately, i don't have a concrete example as yet, still working on the
code for it, and trying to figure out what my options are. i'll try the
"object configuration in command" that you suggest and see if it works. i
think this requires that the CreationFactory be initialized with the correct
model object type at CreateRequest construction.
So it would appear that the CreationFactory itself can only be configured to
the extent of returning a default object of the correct type. Object
initialization must be done with setters after construction. That's a
constraint on the model architecture that's worth knowing about.
regards,
al
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cup9bq$tm4$1@www.eclipse.org...
> Could you give some concrete examples of what you are doing. I don't see
> why the command couldn't "configure" the object created by the request.
>
> "Al Major" <almajor@boxspoon.com> escreveu na mensagem
> news:cup2jl$6t9$1@www.eclipse.org...
> > does this limitation imply that the model object creation pretty much
has
> > to
> > be done in the CreateRequest as currently occurs?
> >
> > in that case, it would appear that the preferred way to influence the
> > initial state of the created object would be to call setter functions,
> > either on the factory or on the created object, prior to calling
> > CreateRequest.getNewObject. presumably all of this would be done in one
of
> > the LayoutEditPolicy.getCreateCommand overrides.
> >
> > is this a reasonable way to proceed? or is there a better way to set the
> > state of the created model object?
> >
> > passing the creation factory into the command as CL suggested would
appear
> > to have the same limitation as the tip. the CreateRequest wouldn't have
> > the
> > object in cache.
> >
> > regards,
> >
> > al
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:cuostt$j1a$1@www.eclipse.org...
> >> The limitation of this tip is that if more than one editpolicy require
> >> access to the object being created, you must use the CreateRequest to
> >> manage/cache the creation. This is rare, but a common scenario would
be
> > if
> >> a layout manager *only* setup constraint info, while a container
> > editpolicy
> >> performed the add.
> >>
> >> "Al Major" <almajor@boxspoon.com> escreveu na mensagem
> >> news:cunn70$c6g$1@www.eclipse.org...
> >> >i came across the following tip in the Redbook on GEF/EMF (top of page
> > 107)
> >> >
> >> > Tip: Actually, your CreationFactory implementation does not need to
> > create
> >> > new model objects. We suggest only submitting the type of the new
model
> >> > object and creating it later in a Command.
> >> >
> >> > this certainly seems plausible. i was wondering if there's any
examples
> > of
> >> > this pattern that i could look at. the GEF samples don't seem to use
> >> > it.
> >> >
> >> > i need to create objects that depend on the location (model
component)
> >> > being
> >> > clicked on. seems like this pattern may be the right way to go about
> >> > it.
> >> > has
> >> > anyone tried this? any suggestions?
> >> >
> >> > regards,
> >> >
> >> > al
> >> >
> >> >
> >>
> >>
> >
> >
>
>
|
|
|
| Re: CreationFactory and create commands [message #168188 is a reply to message #168129] |
Mon, 14 February 2005 16:38 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
I am passing my creation factory into my creation command. But I did
this precisely to avoide the caching of the created object. That is
because my objects are connected to a database and I need to manage
their creation and destruction carefully. The object that is created by
the request is cached by the request until it is actually used by the
command. If you close the app, there is no strategy for disposal of
this created object. But by passing the factory, no object is created
until the command is actually executed.
Furthermore, the request can pass to your command both a model and a
factory if you command requires multiple objects to execute. Or, like
me, your factory can have a different model inside it that it uses to
create the object it returns.
But as with Randy, its hard to know what to recommend without
understanding your problem, or generally your desire.
CL
Al Major wrote:
> unfortunately, i don't have a concrete example as yet, still working on the
> code for it, and trying to figure out what my options are. i'll try the
> "object configuration in command" that you suggest and see if it works. i
> think this requires that the CreationFactory be initialized with the correct
> model object type at CreateRequest construction.
>
> So it would appear that the CreationFactory itself can only be configured to
> the extent of returning a default object of the correct type. Object
> initialization must be done with setters after construction. That's a
> constraint on the model architecture that's worth knowing about.
>
> regards,
>
> al
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cup9bq$tm4$1@www.eclipse.org...
>
>>Could you give some concrete examples of what you are doing. I don't see
>>why the command couldn't "configure" the object created by the request.
>>
>>"Al Major" <almajor@boxspoon.com> escreveu na mensagem
>>news:cup2jl$6t9$1@www.eclipse.org...
>>
>>>does this limitation imply that the model object creation pretty much
>
> has
>
>>>to
>>>be done in the CreateRequest as currently occurs?
>>>
>>>in that case, it would appear that the preferred way to influence the
>>>initial state of the created object would be to call setter functions,
>>>either on the factory or on the created object, prior to calling
>>>CreateRequest.getNewObject. presumably all of this would be done in one
>
> of
>
>>>the LayoutEditPolicy.getCreateCommand overrides.
>>>
>>>is this a reasonable way to proceed? or is there a better way to set the
>>>state of the created model object?
>>>
>>>passing the creation factory into the command as CL suggested would
>
> appear
>
>>>to have the same limitation as the tip. the CreateRequest wouldn't have
>>>the
>>>object in cache.
>>>
>>>regards,
>>>
>>>al
>>>
>>>"Randy Hudson" <none@us.ibm.com> wrote in message
>>>news:cuostt$j1a$1@www.eclipse.org...
>>>
>>>>The limitation of this tip is that if more than one editpolicy require
>>>>access to the object being created, you must use the CreateRequest to
>>>>manage/cache the creation. This is rare, but a common scenario would
>
> be
>
>>>if
>>>
>>>>a layout manager *only* setup constraint info, while a container
>>>
>>>editpolicy
>>>
>>>>performed the add.
>>>>
>>>>"Al Major" <almajor@boxspoon.com> escreveu na mensagem
>>>>news:cunn70$c6g$1@www.eclipse.org...
>>>>
>>>>>i came across the following tip in the Redbook on GEF/EMF (top of page
>>>
>>>107)
>>>
>>>>>Tip: Actually, your CreationFactory implementation does not need to
>>>
>>>create
>>>
>>>>>new model objects. We suggest only submitting the type of the new
>
> model
>
>>>>>object and creating it later in a Command.
>>>>>
>>>>>this certainly seems plausible. i was wondering if there's any
>
> examples
>
>>>of
>>>
>>>>>this pattern that i could look at. the GEF samples don't seem to use
>>>>>it.
>>>>>
>>>>>i need to create objects that depend on the location (model
>
> component)
>
>>>>>being
>>>>>clicked on. seems like this pattern may be the right way to go about
>>>>>it.
>>>>>has
>>>>>anyone tried this? any suggestions?
>>>>>
>>>>>regards,
>>>>>
>>>>>al
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
|
|
|
| Re: CreationFactory and create commands [message #168923 is a reply to message #168188] |
Sun, 20 February 2005 04:13 |
Al Major
Messages: 72
Registered: July 2009 |
Member |
|
|
i'm exploring the architecture of creation using a pre-existing data model
(not one created for GEF). in a couple of weeks i'll probably have a better
sense of what the problems are as the code gets tested.
there's several potential issues related to object construction and lifetime
(including the one that you mentioned about the app being shut down before
the command is executed). another one is that at some point in the editing,
the appropriate initialization parameters (based on the part being selected)
need to be passed in, either to the factory or to the constructed object.
it's possible that these will have simple/standard answers, but i wanted to
check out what's been done already before proceeding. the redbook tip was
one of the architecture options that appeared available. it appears that
there is no working code that i can look at based on that tip, and Randy
pointed out at least one problem with it.
from my understanding of your architecture, it would appear to suffer from
the same problem as the RedBook tip. how do you get around the GEF Request
infrastructure that creates and caches objects, while still using the GEF
architecture (multiple EditPolicies accessing the new object via the
Request)? have you rewritten parts of GEF? or are does your app have special
properties which guarantee that the issue never comes up? do you have sample
code you can share?
since there are apparently no other alternatives that are documented via
code samples, i am currently basing the code on the GEF samples. i'll modify
them to work as necessary. if any issues of general interest come up, i'll
be happy to share if anyone else is interested.
regards,
al
"CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> wrote in message
news:cuqk62$mrj$3@www.eclipse.org...
> I am passing my creation factory into my creation command. But I did
> this precisely to avoide the caching of the created object. That is
> because my objects are connected to a database and I need to manage
> their creation and destruction carefully. The object that is created by
> the request is cached by the request until it is actually used by the
> command. If you close the app, there is no strategy for disposal of
> this created object. But by passing the factory, no object is created
> until the command is actually executed.
>
> Furthermore, the request can pass to your command both a model and a
> factory if you command requires multiple objects to execute. Or, like
> me, your factory can have a different model inside it that it uses to
> create the object it returns.
>
>
> But as with Randy, its hard to know what to recommend without
> understanding your problem, or generally your desire.
>
>
> CL
>
> Al Major wrote:
> > unfortunately, i don't have a concrete example as yet, still working on
the
> > code for it, and trying to figure out what my options are. i'll try the
> > "object configuration in command" that you suggest and see if it works.
i
> > think this requires that the CreationFactory be initialized with the
correct
> > model object type at CreateRequest construction.
> >
> > So it would appear that the CreationFactory itself can only be
configured to
> > the extent of returning a default object of the correct type. Object
> > initialization must be done with setters after construction. That's a
> > constraint on the model architecture that's worth knowing about.
> >
> > regards,
> >
> > al
> >
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:cup9bq$tm4$1@www.eclipse.org...
> >
> >>Could you give some concrete examples of what you are doing. I don't
see
> >>why the command couldn't "configure" the object created by the request.
> >>
> >>"Al Major" <almajor@boxspoon.com> escreveu na mensagem
> >>news:cup2jl$6t9$1@www.eclipse.org...
> >>
> >>>does this limitation imply that the model object creation pretty much
> >
> > has
> >
> >>>to
> >>>be done in the CreateRequest as currently occurs?
> >>>
> >>>in that case, it would appear that the preferred way to influence the
> >>>initial state of the created object would be to call setter functions,
> >>>either on the factory or on the created object, prior to calling
> >>>CreateRequest.getNewObject. presumably all of this would be done in one
> >
> > of
> >
> >>>the LayoutEditPolicy.getCreateCommand overrides.
> >>>
> >>>is this a reasonable way to proceed? or is there a better way to set
the
> >>>state of the created model object?
> >>>
> >>>passing the creation factory into the command as CL suggested would
> >
> > appear
> >
> >>>to have the same limitation as the tip. the CreateRequest wouldn't have
> >>>the
> >>>object in cache.
> >>>
> >>>regards,
> >>>
> >>>al
> >>>
> >>>"Randy Hudson" <none@us.ibm.com> wrote in message
> >>>news:cuostt$j1a$1@www.eclipse.org...
> >>>
> >>>>The limitation of this tip is that if more than one editpolicy require
> >>>>access to the object being created, you must use the CreateRequest to
> >>>>manage/cache the creation. This is rare, but a common scenario would
> >
> > be
> >
> >>>if
> >>>
> >>>>a layout manager *only* setup constraint info, while a container
> >>>
> >>>editpolicy
> >>>
> >>>>performed the add.
> >>>>
> >>>>"Al Major" <almajor@boxspoon.com> escreveu na mensagem
> >>>>news:cunn70$c6g$1@www.eclipse.org...
> >>>>
> >>>>>i came across the following tip in the Redbook on GEF/EMF (top of
page
> >>>
> >>>107)
> >>>
> >>>>>Tip: Actually, your CreationFactory implementation does not need to
> >>>
> >>>create
> >>>
> >>>>>new model objects. We suggest only submitting the type of the new
> >
> > model
> >
> >>>>>object and creating it later in a Command.
> >>>>>
> >>>>>this certainly seems plausible. i was wondering if there's any
> >
> > examples
> >
> >>>of
> >>>
> >>>>>this pattern that i could look at. the GEF samples don't seem to use
> >>>>>it.
> >>>>>
> >>>>>i need to create objects that depend on the location (model
> >
> > component)
> >
> >>>>>being
> >>>>>clicked on. seems like this pattern may be the right way to go about
> >>>>>it.
> >>>>>has
> >>>>>anyone tried this? any suggestions?
> >>>>>
> >>>>>regards,
> >>>>>
> >>>>>al
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
|
|
|
| CreationFactory Problem Example [message #168994 is a reply to message #168114] |
Mon, 21 February 2005 08:48 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Randy Hudson wrote:
> Could you give some concrete examples of what you are doing. I don't see
> why the command couldn't "configure" the object created by the request.
ok. i now have an example:
the constructor for individual model objects takes a parameter, say foo:
class SpecificModelObject : BaseModelObject {
public SpecificModelObject(int foo) {
...
}
}
to set up object creation via the palette, i need something like the
following:
CombinedTemplateCreationEntry component =
new CombinedTemplateCreationEntry(
"SMO",
"Specific Model Object",
SpecificModelObject.class,
new ModelFactory(SpecificModelObject.class, foo),
.....
this will eventually get called from getPaletteRoot when the EditDomain
is being set (well before the model file is loaded). the problem is,
that the value of the parameter foo is not known until after the model
is loaded, so the above code isn't possible.
seems like there's two broad options
a) construct the ModelFactory without parameter foo, i.e. use
new ModelFactory(SpecificModelObject.class);
and then set the value of foo at a later point in the factory's
lifecycle. it appears to me that there's no obvious point at which to do
this. in fact it appears that there's no easy way to grab the factory at
a later point since CreateRequest.getFactory() is not public. (one
ugly option is to have ModelFactory access non local state somehow and
use it acquire foo when getNewObject is called).
b) pass in a fake ModelFactory into the constructor above. use the
"real" ModelFactory from the EditPolicy.getCreateCommand, i.e. instead
of
protected Command getCreateCommand(CreateRequest request) {
CreateCommand crtCmd = new CreateCommand();
crtCmd.setParent((BaseModelObject)(getHost().getModel()));
BaseModelObject newPart
= (BaseModelObject)request.getNewObject();
crtCmd.setChild(newPart);
do the following
protected Command getCreateCommand(CreateRequest request) {
CreateCommand crtCmd = new CreateCommand();
crtCmd.setParent((BaseModelObject)(getHost().getModel()));
SpecificModelObject newPart
= new ModelFactory(SpecificModelObject.class, foo);
// do any initialization for newPart that requires access to the view
.....
crtCmd.setChild(newPart);
of course, option b) just outlined means that you ignore the
CreateRequest infrastructure (the problem that Randy pointed out). in
fact, option b) doesn't even require the use of a CreationFactory, any
construction method should work.
and as pointed out, option a) doesn't seem viable.
is there an obvious answer that i've missed? what are other people doing?
regards,
al
|
|
|
| Re: CreationFactory Problem Example [message #169002 is a reply to message #168994] |
Mon, 21 February 2005 08:56 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
one error in my previous post.
> protected Command getCreateCommand(CreateRequest request) {
> CreateCommand crtCmd = new CreateCommand();
> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
> SpecificModelObject newPart
> = new ModelFactory(SpecificModelObject.class, foo);
> // do any initialization for newPart that requires access to the view
> .....
> crtCmd.setChild(newPart);
should be
protected Command getCreateCommand(CreateRequest request) {
CreateCommand crtCmd = new CreateCommand();
crtCmd.setParent((BaseModelObject)(getHost().getModel()));
SpecificModelObject newPart
// CreationFactory.getNewObject is being called
= (new ModelFactory(
SpecificModelObject.class, foo)).getNewObject();
// do any initialization for newPart that requires access to the view
.....
crtCmd.setChild(newPart);
|
|
|
| Re: CreationFactory and create commands [message #169052 is a reply to message #168923] |
Mon, 21 February 2005 14:58 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> i'm exploring the architecture of creation using a pre-existing data model
> (not one created for GEF). in a couple of weeks i'll probably have a better
> sense of what the problems are as the code gets tested.
>
> there's several potential issues related to object construction and lifetime
> (including the one that you mentioned about the app being shut down before
> the command is executed). another one is that at some point in the editing,
> the appropriate initialization parameters (based on the part being selected)
> need to be passed in, either to the factory or to the constructed object.
>
> it's possible that these will have simple/standard answers, but i wanted to
> check out what's been done already before proceeding. the redbook tip was
> one of the architecture options that appeared available. it appears that
> there is no working code that i can look at based on that tip, and Randy
> pointed out at least one problem with it.
>
> from my understanding of your architecture, it would appear to suffer from
> the same problem as the RedBook tip. how do you get around the GEF Request
> infrastructure that creates and caches objects, while still using the GEF
> architecture (multiple EditPolicies accessing the new object via the
> Request)? have you rewritten parts of GEF? or are does your app have special
> properties which guarantee that the issue never comes up? do you have sample
> code you can share?
>
No, I always follow the GEF Architecture. I thought I had dealt with
this issue, but I check my code and saw a //FIXME, lol. So no im still
suffering from the possibility of dangling database objects. Which i
can clean up with no problem, but that is beside the point.
I think really this caching is just a bad idea. If creating an object
is so heavy that it needs to be cached, then why is their no provision
for disposal if its not used?
I think solving this problem is going to take some GEF changes.
simplest i can think if is an option to turn off the caching.
CL
|
|
|
| Re: CreationFactory Problem Example [message #169061 is a reply to message #168994] |
Mon, 21 February 2005 15:07 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> Randy Hudson wrote:
>
>> Could you give some concrete examples of what you are doing. I don't see
>> why the command couldn't "configure" the object created by the request.
>
>
> ok. i now have an example:
>
> the constructor for individual model objects takes a parameter, say foo:
>
> class SpecificModelObject : BaseModelObject {
> public SpecificModelObject(int foo) {
> ...
> }
> }
>
> to set up object creation via the palette, i need something like the
> following:
>
> CombinedTemplateCreationEntry component =
> new CombinedTemplateCreationEntry(
> "SMO",
> "Specific Model Object",
> SpecificModelObject.class,
> new ModelFactory(SpecificModelObject.class, foo),
> ....
>
> this will eventually get called from getPaletteRoot when the EditDomain
> is being set (well before the model file is loaded). the problem is,
> that the value of the parameter foo is not known until after the model
> is loaded, so the above code isn't possible.
>
foo is not known until after which model is loaded?
The creation is supposed to take place when the Command is executed.
the Command can be undone, and the Command also has a dispose method
that is called when its being disposed. So you want everything to take
place in the Command because that is where you have the best facilities
to govern lifecycle. Also because undo/redo is going to require it
there mostly anyway.
so given the choice, do not create the model within the
getCreateCommand. That method will be called everytime the tool is
activated or when you hover over a Node, etc. its called frequently.
create the model only during the execution phase of the Command itself.
You should be using your own custom CreateCommand. this is not ignoring
the create request infrasturcture. you still get the factory and the
request type through the infrastructure.
what is foo and where is it created?
CL
|
|
|
| Re: CreationFactory and create commands [message #169143 is a reply to message #169052] |
Mon, 21 February 2005 19:42 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Without going back to the redbook, doesn't holding onto the request in the
command, and only calling Request.getNewObject() from within
Command#execute() solve the problem?
> No, I always follow the GEF Architecture. I thought I had dealt with this
> issue, but I check my code and saw a //FIXME, lol. So no im still
> suffering from the possibility of dangling database objects. Which i can
> clean up with no problem, but that is beside the point.
>
> I think really this caching is just a bad idea. If creating an object is
> so heavy that it needs to be cached, then why is their no provision for
> disposal if its not used?
>
> I think solving this problem is going to take some GEF changes. simplest i
> can think if is an option to turn off the caching.
>
>
> CL
|
|
|
| Re: CreationFactory Problem Example [message #169201 is a reply to message #169061] |
Mon, 21 February 2005 23:42 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> foo is not known until after which model is loaded?
foo is something that's picked up from the "diagram" root.
>
> The creation is supposed to take place when the Command is executed. the
> Command can be undone, and the Command also has a dispose method that is
> called when its being disposed. So you want everything to take place in
> the Command because that is where you have the best facilities to govern
> lifecycle. Also because undo/redo is going to require it there mostly
> anyway.
>
how do i get the parent EditPart information from within the command?
do you have some sample code?
regards,
al
|
|
|
| Re: CreationFactory Problem Example [message #169209 is a reply to message #169061] |
Mon, 21 February 2005 23:52 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
are you storing both the parent EditPart and the Request in the command
object? that would be one way to have access to all the required
information at redo/undo time.
regards,
al
|
|
|
| Re: CreationFactory and create commands [message #169225 is a reply to message #169143] |
Tue, 22 February 2005 00:02 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
Randy Hudson wrote:
> Without going back to the redbook, doesn't holding onto the request in the
> command, and only calling Request.getNewObject() from within
> Command#execute() solve the problem?
>
i don't recollect details offhand (and am in the middle of the M5a
upgrade, so can't check), but getNewObject() is called from a couple of
places within GEF code (having to do with selecting the newly created
object). can i assume this is not a problem?
are there any other lifetime issues with doing this? stashing the host
EditPart and Request in the command would address some of the issues
that i'm having.
regards,
al
|
|
|
| Re: CreationFactory and create commands [message #169254 is a reply to message #169143] |
Tue, 22 February 2005 05:00 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
lol, yea. I did solve that problem. Gotta get that comment out. yes,
the problem was I was creating the object within the editPolicy even
before the command was actually executed. Now I pass the request into
the command, and only create when the command is executed, plus the
command has disposal functionality.
My non-db objects are created by the request in the editpolicy, and they
are indeed cached inside the request. my db objects are created by the
request inside the command, and I assume its cached by the request too,
but somehow the request knows its been used and to get a fresh object
next time.
I think it does solve the problem.
CL
Randy Hudson wrote:
> Without going back to the redbook, doesn't holding onto the request in the
> command, and only calling Request.getNewObject() from within
> Command#execute() solve the problem?
>
>
>>No, I always follow the GEF Architecture. I thought I had dealt with this
>>issue, but I check my code and saw a //FIXME, lol. So no im still
>>suffering from the possibility of dangling database objects. Which i can
>>clean up with no problem, but that is beside the point.
>>
>>I think really this caching is just a bad idea. If creating an object is
>>so heavy that it needs to be cached, then why is their no provision for
>>disposal if its not used?
>>
>>I think solving this problem is going to take some GEF changes. simplest i
>>can think if is an option to turn off the caching.
>>
>>
>>CL
>
>
>
|
|
|
| Re: CreationFactory Problem Example [message #169260 is a reply to message #169201] |
Tue, 22 February 2005 05:02 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>>
>> foo is not known until after which model is loaded?
>
>
> foo is something that's picked up from the "diagram" root.
>
>>
>> The creation is supposed to take place when the Command is executed.
>> the Command can be undone, and the Command also has a dispose method
>> that is called when its being disposed. So you want everything to
>> take place in the Command because that is where you have the best
>> facilities to govern lifecycle. Also because undo/redo is going to
>> require it there mostly anyway.
>>
> how do i get the parent EditPart information from within the
> command? do you have some sample code?
>
> regards,
>
> al
my commands deal in models only and have no knowledge of edit parts.
any info tht the command needs is put into it by the editPolicy when the
command is created.
CL
|
|
|
| Re: CreationFactory Problem Example [message #169268 is a reply to message #169209] |
Tue, 22 February 2005 05:03 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> are you storing both the parent EditPart and the Request in the command
> object? that would be one way to have access to all the required
> information at redo/undo time.
>
> regards,
>
> al
no but i store the editPart's model and in this case the request as
well. Though I dont really like havin the request in there. It works
though.
CL
|
|
|
| Re: CreationFactory Problem Example [message #169276 is a reply to message #169268] |
Tue, 22 February 2005 08:01 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
CL [dnoyeb] Gilbert wrote:
>
>
> no but i store the editPart's model and in this case the request as
> well. Though I dont really like havin the request in there. It works
> though.
>
>
> CL
so it appears from your comments that your code looks something like
this. in the model class
class SpecificModelObject : BaseModelObject {
public SpecificModelObject(int foo) {
...
}
}
in the templatecreationentry for the palette
CombinedTemplateCreationEntry component =
new CombinedTemplateCreationEntry(
"SMO",
"Specific Model Object",
SpecificModelObject.class,
new ModelFactory(SpecificModelObject.class),
.....
and then the following code in an EditPolicy.
protected Command getCreateCommand(CreateRequest request) {
CreateCommand crtCmd = new CreateCommand();
crtCmd.setParent((BaseModelObject)(getHost().getModel()));
crtCmd.setRequest(request);
// do any initialization for the command that requires view data
....
crtCmd.setModelData(...);
....
and the actual creation is finally done in CreateCommand.redo() as
....
BaseModelObject obj = (BaseModelObject)request.getNewObject();
// use the initialization data to initialize obj
if (obj instanceof SpecificModelObject) {
obj.init(....);
}
....
is this a fair representation of what your code does?
this will not work for me, because "foo" is not available when the
factory is created (in CombinedTemplateCreationEntry). i need access to
the host EditPart to get the value of foo.
i'd like to be able to initalize CreationFactory with "foo" in the
EditPolicy.getCreateCommand. however CreateRequest.getFactory is not
public, so i cannot do this.
what i _can_ do is use CreateRequest.setFactory as follows:
protected Command getCreateCommand(CreateRequest request) {
CreateCommand crtCmd = new CreateCommand();
crtCmd.setParent((BaseModelObject)(getHost().getModel()));
// get the value for foo
foo = getFoo(getHost());
// change factory
request.setFactory(new ModelFactory(SpecificModelObject.class, foo))
crtCmd.setRequest(request);
// do any initialization for the command that requires view data
....
crtCmd.setModelData(...);
i think this will work as long as i'm careful that no other EditPolicy
calls request.getNewObject first.
is this way of resetting the factory acceptable? or not a good idea? if
it's not a good idea, is there some other way to achieve the same effect?
regards,
al
|
|
|
| Re: CreationFactory Problem Example [message #169284 is a reply to message #169276] |
Tue, 22 February 2005 10:32 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
upon further consideration, i realized that i also need to use the
remembered object type.
protected Command getCreateCommand(CreateRequest request) {
CreateCommand crtCmd = new CreateCommand();
crtCmd.setParent((BaseModelObject)(getHost().getModel()));
// get the value for foo
foo = getFoo(getHost());
// change factory using remembered object type
request.setFactory(new ModelFactory(request.getObjectType(), foo))
crtCmd.setRequest(request);
// do any initialization for the command that requires view data
....
crtCmd.setModelData(...);
after this final change, this code is looking like the RedBook
suggestion. the one difference is that we now replace the initial
CreationFactory (which effectively does nothing except remember the
type) with a new one that can create the object (the redbook suggestion
seems to bypass the CreationFactory mechanism altogether).
so this potentially is subject to the same problems as the redbook
suggestion.
is there a safer place in the CreateRequest lifecycle to change the
factory being used? perhaps in the code for the EditPart (instead of in
an EditPolicy)?
regards,
al
|
|
|
| Re: CreationFactory Problem Example [message #169398 is a reply to message #169276] |
Wed, 23 February 2005 13:51 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> CL [dnoyeb] Gilbert wrote:
>
>>
>>
>> no but i store the editPart's model and in this case the request as
>> well. Though I dont really like havin the request in there. It works
>> though.
>>
>>
>> CL
>
>
> so it appears from your comments that your code looks something like
> this. in the model class
>
> class SpecificModelObject : BaseModelObject {
> public SpecificModelObject(int foo) {
> ...
> }
> }
>
> in the templatecreationentry for the palette
>
> CombinedTemplateCreationEntry component =
> new CombinedTemplateCreationEntry(
> "SMO",
> "Specific Model Object",
> SpecificModelObject.class,
> new ModelFactory(SpecificModelObject.class),
> ....
>
> and then the following code in an EditPolicy.
>
> protected Command getCreateCommand(CreateRequest request) {
> CreateCommand crtCmd = new CreateCommand();
> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
> crtCmd.setRequest(request);
> // do any initialization for the command that requires view data
> ....
> crtCmd.setModelData(...);
>
> ...
basically, but what do you mean by view data? if its part of the view,
its handled by the editpart that eventually will be created from this
new model.
>
> and the actual creation is finally done in CreateCommand.redo() as
>
> ...
> BaseModelObject obj = (BaseModelObject)request.getNewObject();
> // use the initialization data to initialize obj
> if (obj instanceof SpecificModelObject) {
> obj.init(....);
> }
> ...
well mine is done in execute, and redo just grabs old undone already
existing objects.
again, i dont really know what kind of initialization you do here? My
objects are modified somewhat when they get added to the container
though. so their parent will init them i guess.
>
> is this a fair representation of what your code does?
>
> this will not work for me, because "foo" is not available when the
> factory is created (in CombinedTemplateCreationEntry). i need access to
> the host EditPart to get the value of foo.
>
You should not need the host editPart, but you may need its model. If
so this model is available when getCreateCommand is called right?
> i'd like to be able to initalize CreationFactory with "foo" in the
> EditPolicy.getCreateCommand. however CreateRequest.getFactory is not
> public, so i cannot do this.
>
Cant you just add foo to the command?
> what i _can_ do is use CreateRequest.setFactory as follows:
>
> protected Command getCreateCommand(CreateRequest request) {
> CreateCommand crtCmd = new CreateCommand();
> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
>
> // get the value for foo
> foo = getFoo(getHost());
> // change factory
> request.setFactory(new ModelFactory(SpecificModelObject.class, foo))
>
> crtCmd.setRequest(request);
> // do any initialization for the command that requires view data
> ....
> crtCmd.setModelData(...);
>
are you saying you need 'foo' to be able to create this new model? still
i dont see why foo cant be added to the Command and used from within.
Why is foo only available when getCreateCommand is called? foo can't be
added when the factory is created?
> i think this will work as long as i'm careful that no other EditPolicy
> calls request.getNewObject first.
>
> is this way of resetting the factory acceptable? or not a good idea? if
> it's not a good idea, is there some other way to achieve the same effect?
>
seems like something is wrong.
|
|
|
| Re: CreationFactory Problem Example [message #169405 is a reply to message #169276] |
Wed, 23 February 2005 13:55 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> CL [dnoyeb] Gilbert wrote:
>
>>
>>
>> no but i store the editPart's model and in this case the request as
>> well. Though I dont really like havin the request in there. It works
>> though.
>>
>>
>> CL
>
>
> so it appears from your comments that your code looks something like
> this. in the model class
>
> class SpecificModelObject : BaseModelObject {
> public SpecificModelObject(int foo) {
> ...
> }
> }
>
> in the templatecreationentry for the palette
>
> CombinedTemplateCreationEntry component =
> new CombinedTemplateCreationEntry(
> "SMO",
> "Specific Model Object",
> SpecificModelObject.class,
> new ModelFactory(SpecificModelObject.class),
> ....
>
> and then the following code in an EditPolicy.
>
> protected Command getCreateCommand(CreateRequest request) {
> CreateCommand crtCmd = new CreateCommand();
> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
> crtCmd.setRequest(request);
> // do any initialization for the command that requires view data
> ....
> crtCmd.setModelData(...);
>
> ...
>
> and the actual creation is finally done in CreateCommand.redo() as
>
> ...
> BaseModelObject obj = (BaseModelObject)request.getNewObject();
> // use the initialization data to initialize obj
> if (obj instanceof SpecificModelObject) {
> obj.init(....);
> }
> ...
>
> is this a fair representation of what your code does?
>
> this will not work for me, because "foo" is not available when the
> factory is created (in CombinedTemplateCreationEntry). i need access to
> the host EditPart to get the value of foo.
>
> i'd like to be able to initalize CreationFactory with "foo" in the
> EditPolicy.getCreateCommand. however CreateRequest.getFactory is not
> public, so i cannot do this.
>
> what i _can_ do is use CreateRequest.setFactory as follows:
>
> protected Command getCreateCommand(CreateRequest request) {
> CreateCommand crtCmd = new CreateCommand();
> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
>
> // get the value for foo
> foo = getFoo(getHost());
seems like you can add the host to the factory when the factory is
created. and you can add this getFoo() method to your factory as well.
so when the model is requested you will be able to call
getFoo(getHost()) from within the factory?
CL
|
|
|
| Re: CreationFactory Problem Example [message #169428 is a reply to message #169405] |
Wed, 23 February 2005 14:22 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
> seems like you can add the host to the factory when the factory is
> created. and you can add this getFoo() method to your factory as well.
> so when the model is requested you will be able to call
> getFoo(getHost()) from within the factory?
>
>
> CL
to the best of my knowledge the factory used within the CreateRequest is
created here (at least for palette tools):
>>
>> in the templatecreationentry for the palette
>>
>> CombinedTemplateCreationEntry component =
>> new CombinedTemplateCreationEntry(
>> "SMO",
>> "Specific Model Object",
>> SpecificModelObject.class,
>> new ModelFactory(SpecificModelObject.class),
>> ....
>>
the code above is called by getPaletteRoot in the constructor of the
GEF editor (setEditDomain). it's about the first thing that happens in
the editor's lifecycle. the model isn't available yet, and therefore
neither are any editparts based on the model.
i don't know if there's a way of resetting the factory in each
CombinedTemplateCreationEntry after a model is created (or loaded). that
would be an acceptable solution, but API to do this doesn't seem to exist.
so how do i add the value of "foo" to the factory? this is the question
that i'm trying to answer. where in the GEF lifecycle for
tools/factories/requests should i introduce "foo" into the factory?
i think the problem is clear. it would help me if you could outline
your solutions in pseudo-code.
al
|
|
|
| Re: CreationFactory Problem Example [message #169434 is a reply to message #169398] |
Wed, 23 February 2005 14:37 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>>
>> protected Command getCreateCommand(CreateRequest request) {
>> CreateCommand crtCmd = new CreateCommand();
>> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
>> crtCmd.setRequest(request);
>> // do any initialization for the command that requires view data
>> ....
>> crtCmd.setModelData(...);
>>
>> ...
>
>
> basically, but what do you mean by view data? if its part of the view,
> its handled by the editpart that eventually will be created from this
> new model.
>
for output, yes the editpart will eventually handle it. but initial
defaults for the model (such as size, position, color, font, etc) will
in general depend on the view data at the time of creation. or are you
suggesting that the initialization (of size and position) can wait till
the EditPart is eventually created? that somehow seems wrong.
>
>>
>> and the actual creation is finally done in CreateCommand.redo() as
>>
>> ...
>> BaseModelObject obj = (BaseModelObject)request.getNewObject();
>> // use the initialization data to initialize obj
>> if (obj instanceof SpecificModelObject) {
>> obj.init(....);
>> }
>> ...
>
>
> well mine is done in execute, and redo just grabs old undone already
> existing objects.
>
> again, i dont really know what kind of initialization you do here? My
> objects are modified somewhat when they get added to the container
> though. so their parent will init them i guess.
>
i should have mentioned, in this case execute just calls redo.
in general, both the model (egs. type of parent) and the view (size,
positioning, color) will carry information that will be required to
intialize the new object. both of these pieces of information can be
passed into the CreateCommand.
>> this will not work for me, because "foo" is not available when the
>> factory is created (in CombinedTemplateCreationEntry). i need access to
>> the host EditPart to get the value of foo.
>>
>
> You should not need the host editPart, but you may need its model. If
> so this model is available when getCreateCommand is called right?
>
you're right, in general i just need to pass in the model and any view
specific information (coordinates, sizes, colors, fonts) that may be
needed on creation. the whole EditPart may not be required.
but by the same token, it should not be necessary to pass the Request
into the command when all you want is the creationfactory. i'm actually
having difficulty with this because my commands may be used from outside
GEF (now that the commandstack is moving into the platform). i'd rather
not have GEF dependencies in the commands if i can avoid it.
>
>> i'd like to be able to initalize CreationFactory with "foo" in the
>> EditPolicy.getCreateCommand. however CreateRequest.getFactory is not
>> public, so i cannot do this.
>>
>
> Cant you just add foo to the command?
>
as i mention in another post, "foo" eventually is needed for the object
construction which happens inside the factory. adding it to the command
just delays the point at which it needs to be injected into the factory.
>
>> what i _can_ do is use CreateRequest.setFactory as follows:
>>
>> protected Command getCreateCommand(CreateRequest request) {
>> CreateCommand crtCmd = new CreateCommand();
>> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
>>
>> // get the value for foo
>> foo = getFoo(getHost());
>> // change factory
>> request.setFactory(new ModelFactory(SpecificModelObject.class, foo))
>>
>> crtCmd.setRequest(request);
>> // do any initialization for the command that requires view data
>> ....
>> crtCmd.setModelData(...);
>>
>
> are you saying you need 'foo' to be able to create this new model? still
> i dont see why foo cant be added to the Command and used from within.
> Why is foo only available when getCreateCommand is called? foo can't be
> added when the factory is created?
>
discussed in the other post on this topic.
|
|
|
| Re: CreationFactory Problem Example [message #169727 is a reply to message #169434] |
Fri, 25 February 2005 17:09 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
>>>
>>> protected Command getCreateCommand(CreateRequest request) {
>>> CreateCommand crtCmd = new CreateCommand();
>>> crtCmd.setParent((BaseModelObject)(getHost().getModel()));
>>> crtCmd.setRequest(request);
>>> // do any initialization for the command that requires view data
>>> ....
>>> crtCmd.setModelData(...);
>>>
>>> ...
>>
>>
>>
>> basically, but what do you mean by view data? if its part of the view,
>> its handled by the editpart that eventually will be created from this
>> new model.
>>
>
> for output, yes the editpart will eventually handle it. but initial
> defaults for the model (such as size, position, color, font, etc) will
> in general depend on the view data at the time of creation. or are you
> suggesting that the initialization (of size and position) can wait till
> the EditPart is eventually created? that somehow seems wrong.
>
Ahh. I didnt implement the color and line sizing things that would
influence the created model yet, so perhaps I have not crossed this issue.
I would let the factory handle this, thats what factories do after all.
See the other post.
>>
>>>
>>> and the actual creation is finally done in CreateCommand.redo() as
>>>
>>> ...
>>> BaseModelObject obj = (BaseModelObject)request.getNewObject();
>>> // use the initialization data to initialize obj
>>> if (obj instanceof SpecificModelObject) {
>>> obj.init(....);
>>> }
>>> ...
>>
>>
>>
>> well mine is done in execute, and redo just grabs old undone already
>> existing objects.
>>
>> again, i dont really know what kind of initialization you do here? My
>> objects are modified somewhat when they get added to the container
>> though. so their parent will init them i guess.
>>
> i should have mentioned, in this case execute just calls redo.
>
> in general, both the model (egs. type of parent) and the view (size,
> positioning, color) will carry information that will be required to
> intialize the new object. both of these pieces of information can be
> passed into the CreateCommand.
>
my size/position is set when my model is added to its parent because
that is where the layout occurs. but color I understand.
I would put this into the factory instead since the create command is
created by the edit policy, and I am not sure you have access to the
editor (which is where the color and line thickness, etc would be set)
when this is happening.
>>> this will not work for me, because "foo" is not available when the
>>> factory is created (in CombinedTemplateCreationEntry). i need access to
>>> the host EditPart to get the value of foo.
>>>
>>
>> You should not need the host editPart, but you may need its model. If
>> so this model is available when getCreateCommand is called right?
>>
>
> you're right, in general i just need to pass in the model and any
> view specific information (coordinates, sizes, colors, fonts) that may
> be needed on creation. the whole EditPart may not be required.
>
> but by the same token, it should not be necessary to pass the
> Request into the command when all you want is the creationfactory. i'm
> actually having difficulty with this because my commands may be used
> from outside GEF (now that the commandstack is moving into the
> platform). i'd rather not have GEF dependencies in the commands if i can
> avoid it.
>
Exactly. My models are pure java. No SWT, no GEF, nothing. I even
convert from eclipse type Point to java.awt.Point when I need to because
my models only know java.awt.point. That is why I complained about
passing the request into my command ;) This is why I insist on not
passing the edit part into the command. I try to make my commands pure
java as well.
>>
>>> i'd like to be able to initalize CreationFactory with "foo" in the
>>> EditPolicy.getCreateCommand. however CreateRequest.getFactory is not
>>> public, so i cannot do this.
>>>
>>
>> Cant you just add foo to the command?
>>
> as i mention in another post, "foo" eventually is needed for the
> object construction which happens inside the factory. adding it to the
> command just delays the point at which it needs to be injected into the
> factory.
>
see other post.
|
|
|
| Re: CreationFactory Problem Example [message #169732 is a reply to message #169428] |
Fri, 25 February 2005 17:15 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Al Major wrote:
> > seems like you can add the host to the factory when the factory is
> > created. and you can add this getFoo() method to your factory as well.
> > so when the model is requested you will be able to call
> > getFoo(getHost()) from within the factory?
> >
> >
> > CL
>
> to the best of my knowledge the factory used within the CreateRequest is
> created here (at least for palette tools):
>
>>>
>>> in the templatecreationentry for the palette
>>>
>>> CombinedTemplateCreationEntry component =
>>> new CombinedTemplateCreationEntry(
>>> "SMO",
>>> "Specific Model Object",
>>> SpecificModelObject.class,
>>> new ModelFactory(SpecificModelObject.class),
>>> ....
>>>
>
> the code above is called by getPaletteRoot in the constructor of the
> GEF editor (setEditDomain). it's about the first thing that happens in
> the editor's lifecycle. the model isn't available yet, and therefore
> neither are any editparts based on the model.
>
Why do you care about edit parts, or what info do they contain u are
after? Try this;
CombinedTemplateCreationEntry component =
new CombinedTemplateCreationEntry(
"SMO",
"Specific Model Object",
SpecificModelObject.class,
new MyFactory(SpecificModelObject.class),
....
private class MyFactory {
//this factory is an inner class and has access to the editor.
//and as a result all color and size settings of its tools
//also has access to the editors model if necessary but its
//probably not since that should be available in the edit
//policy anyway
}
it does not matter that when the factory is created the model will be
null. GEF if used properly will ensure that the factory is never called
if no model is present, because if no model is present, the Editor
should/will be closed.
> i don't know if there's a way of resetting the factory in each
> CombinedTemplateCreationEntry after a model is created (or loaded). that
> would be an acceptable solution, but API to do this doesn't seem to exist.
>
> so how do i add the value of "foo" to the factory? this is the
> question that i'm trying to answer. where in the GEF lifecycle for
> tools/factories/requests should i introduce "foo" into the factory?
>
> i think the problem is clear. it would help me if you could outline
> your solutions in pseudo-code.
>
> al
CL
|
|
|
| Re: CreationFactory Problem Example [message #169755 is a reply to message #169732] |
Sun, 27 February 2005 02:21 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
>
> Why do you care about edit parts, or what info do they contain u are
> after? Try this;
>
> CombinedTemplateCreationEntry component =
> new CombinedTemplateCreationEntry(
> "SMO",
> "Specific Model Object",
> SpecificModelObject.class,
> new MyFactory(SpecificModelObject.class),
> ...
>
> private class MyFactory {
> //this factory is an inner class and has access to the editor.
> //and as a result all color and size settings of its tools
> //also has access to the editors model if necessary but its
> //probably not since that should be available in the edit
> //policy anyway
> }
>
i didn't think of this. i'm not sure it'll work, but definitely worth
looking at. thanks! i'll post back with results.
al
|
|
|
Goto Forum:
Current Time: Fri Apr 26 14:06:35 GMT 2024
Powered by FUDForum. Page generated in 0.06400 seconds |
] 
Search
Help
Register
Login
Home
