[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.emf] Re: newbiew qn: how to add a viewer to the EMF editor plugin 
Charles,

Comments below.

Charles Martin wrote:
> Charles,
> > Comments below.
> > Charles Martin wrote:
> > Thanks Ed
> > > > So while the undo feature of EMF is quite nice,
> for my application, I don't really need it. What I
> need (I think) is to know the best way to acquire and
> release a lock on an EMF resource.
> > > This makes me think you aren't so much tracking
> user's changes but > something else since users always want to be able to
> undo the changes > they make directly.

This is for a near-real time trading application. The user views the market data, and enters potential positions.  They don't undo anything.  if they don't like what they enter, they don't undo it--they simply hit the clear button and  then enter a new position.  For now, that's all I need.

I say near real time because the analysis takes upto a minute. This is fine for this application.
I see.
> > See, I need to be able to track when the resource
> lock is acquired and when it is released because I
> need to synchronize my views (plots) with the default
> resource editor. This is because plots can take up
> to 1 minute to compute, and I don't want to lock the
> entire GUI while the plot calculations are running.
> But at the same time, I don't want the user editing
> the EMF resource while a plot is being computed.
> That is, I don't want the user to try to reload the
> EMF model from the database, or to change any of the
> EMF model attributes. So I would like to detect
> when the Plot View acquires the lock on the EMF
> resource so the Editor Load Action can be disabled.
> > > his makes me think that in some ways it's more like a
> wholesale > resource update kind of issue and obviously isn't a
> set of user changes > you'd want to undo. In fact, it's probably most
> similar to how the > editor would respond after getting a resource delta
> in the workspace. > I.e., the existing model needs to be unloaded,
> reloaded with the new > version, and then command stack needs to be flushed
> because the state is > inconsistent.

There are two types of changes. One is a wholesale update of all data. The other is small change the user makes. It is true I could treat both kinds of changes as wholesale updates, and I will do this at first. Later, I will want to optimize and listen for minor changes 

Thanks for note abourt flushing the command stack.

> > At first it seemed as if the EMF Transaction
> Model would be a good choice, but I am not 100%.
> Certainly I do want to be able to load a resource
> and modify it, and the EMF Transaction Model
> supports this.
> > , that part is good, but I do get the sense there is
> more going on > than just editing. I.e., I don't see the plot
> generation as an undoable > editing step.

The only undo is just "clear." I suppose I culd use the undo facility of EMF to implement this, but there is no need to since it is so simple.
Makes sense.
> > But it also seems that here I need to acquire a
> lock the EMF model without ever modifying it
> (except, perhaps, to set a flag saying that the lock
> has been acquired)
> > > It's possible via the editing domain to mark a
> resource as read only and > thereby disable all modification commands for it.
> > So what I am little unclear on, however, is how
> to know when the lock as actually be acquired by the
> TransactionEditiongDomain, or whether I should simply
> ad a flag to my EMF model to indicate is locked? > > > I get the sense that perhaps you should be generating
> the plot as a > separate job that does it's work in the background
> and whose behavior is > not visible to the UI. Perhaps during that period,
> editing of the model > should be prevented by making the resource behave as
> if it's read only. > Likely before the job begins, you'd need to consider
> if the model is > already dirty and if the end result of the job would
> be to lose changes.
> >

That is exactly what I am going to do. So I need to know when the model becomes "dirty" so I can display this with a visual cue--that's why I want to know when the lock is aquired
Typically dirtiness is tracked by virtue of there being commands on the stack. I'm not sure there is a way to listen for the locks; Christian would know best.
Is there a better way to track the EMF state?
It's also possible to directly tack the modification of a resource to know it's changed, but this has no undo awareness so making a change and undoing it will continue to leave the resource as modified.


> > I assume the (only) way to do this is to use an
> EditingCommand to set a flg on the EMF model to
> indicate a lock has been aquired, and to attach a
> Resource ResourceSetListener to the
> TranactionalEditingDomain that sends processing the
> notification that that the resource has been changed.
> > > > I'm not entirely clear how the generated plot relates
> to what the user > is editing. Are there really two models? The data
> being fed into the > plot and the plot that's produced from their data?
> Is the later > ditable or only the former? If only the input data
> is editable and the > plot is like a derived model, you'd probably want to
> have a read > transaction for the data and cooperatively yield so
> that the UI isn't > locked out. When the plot is done, you'd likely want
> to completely > replace the plot currently being viewed. I.e., don't
> modify the > existing plot but rather replace it after it's
> recomputed...
> > 

Yeah, something like this, however, the plot will respond to user edits and reads--you can think of the EMF editor as a join on two SQL tables--one is read from the database every 5 minutes, the other is being edited by the user and persists in time.  The plot  depends on both.

I'll think about what the "read transaction" and see if i can get that work work.

> > Or perhaps I should just be using the standard
> Eclipse locking mechanism in the Eclipse 3.0 Jobs API
> What makes this a bit confusing is some of the
> on-line example assumes the use of the
> ResourcesPlugin (i.e. not an RCP):
> > ortunately, assumptions about workspace resources
> being used have > tended to permeate a lot of APIs. I suspect you
> would want to make use > of Jobs for this type of thing; the transaction
> support will help with > controlled access from such jobs.
> >
> http://www.eclipse.org/articles/Article-Concurrency/jo
> bs-api.html
> >
> >
> > I guess it is still just a bit confusing how the
> EMF use of resources differs from the Eclipse
> ResourcesPlugin ? > EMF's resources are designed to support a purely
> RESTful style of > access. No assumptions are made about how the
> contents for URIs are set > and retrieved and all access is delegated to the
> URIConverter; EMF 2.4 > strengthens these APIs further to support the full
> life cycle, including > delete. Eclipse's workspace is more analogous in
> some ways to a > repository where you can always know the full closure
> of all the data > known to the application (what I often refer to as a
> closed world model > as opposed to REST which is an open world model
> because the data space > knows no bounds).

Thanks.

> > At first I naively thought I could just take
> advantage of the Eclipse Resources Plugin and the
> ResourceChangeNotifications there, but after having
> look at this a while, it appears that this is NOT the
> thing to do with EMF (especially for an Eclipse EMF
> RCP).
> > > I suppose you could if the plot itself was saved to a
> resource and the > editor was displaying the contents of that resource.
> > Of course, I could just "punt" and use the Java
> 1.5 Concurrency Libraries and manage the locks
> myself, but this just does not seem to be the Eclipse
> way or the EMF way.
> > > I think you'd likely want to use jobs.

Thanks.  I'll see what I can do.

> > Again, any clarification is appreciated, and I am
> continuing to plug through as much of this as I can.
> > > Probably I don't quite understand how the user's data
> is related to the > plot and if the plot itself is editable or just
> something that's viewed.

Yeah, I thought if I shared some details it might be easier to understand. Actually the whole application is quite straightforward, except for the threading.

> > Thanks again
> >
> > Charles
> >
> > P.S. I have also considered using the Eclipse
> framework for Natures and Builders to treat my
> calculations like a compilation, and to have a "run
> button" . Still, this is a bit of an overkil for
> what I am doing presently, and I still am not 100%
> sure how to intermingle this with EMF, and within an
> RCP.
> > > Yes, I suppose the question is do you want to have a
> plot resource that > keeps itself up-to-date whenever the inputs change.
> Certainly that > pproach turns it into a simpler problem of unload and
> reloading a > resource based on a workspace delta...

It really is just an issue of consistency...if the EMF model becomes dirty, then the plot is invalid. If the plot is calculating, then the editor has to be disabled. My kneejerk first design is just to place a mutex lock in the main Plugin class and post a message to every view/editor whenever the lock is acquired or released. I have just been trying to see if the Eclipse platform and/or the EMF framework has it's own way of doing this which is more natural.
I imagine you should be launching a job and while the job is running be disabled. When the job completes, you can be notified.